Image Line

reflex · Post by **reflex** » Fri Sep 05, 2008 6:32 pm

aMUSEd wrote:Oh the hint bar says it's 1.0 so no wonder - where do I get the updated version from then?

Either from your IL user account page, or from the Ogun page on the www.image-line.com site.

But you may just have to clear your browser's cache.

aMUSEd · Post by **aMUSEd** » Fri Sep 05, 2008 6:35 pm

I downloaded it from my account but I've realised what I did wrong - the installer is a different name from the one I downloaded yesterday (ogun install not ogun vsti install) and I assumed it had overwritten the old one when in fact it had gone somewhere else so I was installing the old one again.

chilln · Post by **chilln** » Sun Sep 07, 2008 4:56 pm

Thanks reflex,

Ogun (1.0.1) loads up in KORE2 for me now, too.

Cheers!

mystran · Post by **mystran** » Mon Sep 08, 2008 1:43 pm

reflex wrote:Yes this is an old problem, but I don't know how to fix it from the plugin side. The problem is that the window doesn't seem to receive "repaint" messages in the normal manner, but this as far as I know this depends on the host's plugin window (the one that the Ogun window is on). I might be able to fix it one day, but I can't promise it.

You could try using CS_SAVEBITS on the windowclass for the menus (which is what that class style is designed for) which causes it to save what's under the window, such that system can draw what was behind it without issuing any WM_PAINT messages to anyone...

http://msdn.microsoft.com/en-us/library ... ass_styles for more info.

reflex · Post by **reflex** » Mon Sep 08, 2008 2:30 pm

mystran wrote:You could try using CS_SAVEBITS on the windowclass for the menus (which is what that class style is designed for) which causes it to save what's under the window, such that system can draw what was behind it without issuing any WM_PAINT messages to anyone...

Thanks, that does seem to help. I'll experiment with it some more.

tony tony chopper · Post by **tony tony chopper** » Mon Sep 08, 2008 3:23 pm

You could try using CS_SAVEBITS on the windowclass for the menus

Fred says that it works, so we'll probably keep it (until we realize it causes other, worse troubles, as usual).

But it's weird that it works (plus, why is there a problem in some hosts only?), considering our menus are transparent, so basically layered windows, meaning that stuff behind still animates while the menus are there anyway. Normally layered windows are part of the desktop composition & don't really obscure windows underneath. So it's weird that CS_SAVEBITS does anything.

mystran · Post by **mystran** » Mon Sep 08, 2008 8:31 pm

tony tony chopper wrote:
You could try using CS_SAVEBITS on the windowclass for the menus
Fred says that it works, so we'll probably keep it (until we realize it causes other, worse troubles, as usual).

Let me guess.. if something below the window has changed before it closes, you'll get what was below the window when it opened? Or something similar or equally ugly.

But it's weird that it works (plus, why is there a problem in some hosts only?), considering our menus are transparent, so basically layered windows, meaning that stuff behind still animates while the menus are there anyway. Normally layered windows are part of the desktop composition & don't really obscure windows underneath. So it's weird that CS_SAVEBITS does anything.

Oh ok. Layered eh? Oh the joy (I see it now, it's just that the menus that overlap host-drawn stuff are transparent so slightly that I thought those aren't layered at first). But yeah, CS_SAVEBITS shouldn't make a difference with composition.

Remember some strange problems with layered windows when I played with 'em ages ago (maybe on W2k, which doesn't even support WS_EX_COMPOSITED that you need for double buffered composition); just can't remember what I did to solve those. Then again it could have been I tried something like using layering on child windows (which isn't supposed to work at all) or with CS_OWNDC (which I don't even understand why it's not allowable) or some similar stuff.

Anyway, if layering works.. I wonder if it'd still fail if one draws the the window once set to fully transparent (that is, just what's behind it) just before actually hiding/destroying it. Or maybe disable layering (with SetWindowLong) just before destroying, or something similar.

Oh well, sorry for not being able to help after all.

tony tony chopper · Post by **tony tony chopper** » Mon Sep 08, 2008 9:23 pm

But yeah, CS_SAVEBITS shouldn't make a difference with composition

But Fred says that it works, that's what's strange. In FL it makes no diff, as expected.

I never had problems with layered windows, in fact, I had countless troubles with normal windows & their truckloads of special flags, but layered windows are so simply 'sprites' floating over windows, that not much can go wrong with them.
I only wish 'additive' blending worked with them, and it works with some graphic drivers, but not officially & not in all cases, sadly. Otherwise, having colors with no alpha nicely blends in add mode, great for special effects.

Our menus get more transparent for submenus that are unfocused btw (to show where the active menu is), and in some other cases

mystran · Post by **mystran** » Mon Sep 08, 2008 9:46 pm

Our menus get more transparent for submenus that are unfocused btw (to show where the active menu is), and in some other cases

Yes I know; FL is my main host after all. I like it how it looks nice, yet since the active menu isn't too transparent it's still possible to read it easily. People often make the mistake of using so much transparency that it gets hard to read; though blurring the background helps.. not that I know how to do it on Windows, even though on Vista it should be possible (and your WaveCandy does it). Just got used to having a transparent terminal (and GVim for that matter) with background blurred back when I was using Linux (and Compiz on it) more actively.

Btw, is this bug related to the issue where when you set a plugin window in FL "detached", it won't ever redraw the background when you move the newly-detached plugin window, unless you use a non-detached window to force redraw (or something else, like minimize+remaximize FL)?

tony tony chopper · Post by **tony tony chopper** » Mon Sep 08, 2008 9:58 pm

Btw, is this bug related to the issue where when you set a plugin window in FL "detached", it won't ever redraw the background when you move the newly-detached plugin window,

yes, that's a (one of the many) Vista issue that I fixed recently.

reflex · Post by **reflex** » Tue Sep 09, 2008 6:32 am

mystran wrote:Let me guess.. if something below the window has changed before it closes, you'll get what was below the window when it opened? Or something similar or equally ugly.

Strangely, no.

Oh well, sorry for not being able to help after all.

No, you did help.

tony tony chopper · Post by **tony tony chopper** » Tue Sep 09, 2008 3:04 pm

the bug is probably related to the trick I use to flicker-freely make the menu's selected item fade out, by changing its region on the fly.

In fact, Vista has a bug with window regions. Set a window's region to nothing & then back to full very quickly, and sometimes the window just disappears (but only visually - you can still click everywhere).
I was using this because it worked better than LockWindowUpdate on XP. It has become pretty hard to lock refreshing on a window (& of course WM_SETREDRAW only works with 2 or 3 controls).

ronergeist · Post by **ronergeist** » Fri Sep 12, 2008 7:45 am

So can we expect a fix for this bug soonish?

reflex · Post by **reflex** » Fri Sep 12, 2008 7:48 am

ronergeist wrote:So can we expect a fix for this bug soonish?

Have you tried Ogun 1.0.2 yet?

ronergeist · Post by **ronergeist** » Fri Sep 12, 2008 3:53 pm

reflex wrote:
ronergeist wrote:So can we expect a fix for this bug soonish?
Have you tried Ogun 1.0.2 yet?

It seems much better now, but there are still som glitches when changing presets from the menu e.g.

Image Line

KVR Audio

Ogun - a bug