Jump to content

Floating Front Panels Loosing their "Floatiness"


Recommended Posts

So I have a few VIs which I use as fancy tool-tip windows. Basically really small front panels that get moved around at will when the user moves their mouse in the owning VI. The tool-tip is set to a floating window via the VI properties, runs without borders, title bars, etc. There's no fancy Win32 stuff going on behind the scenes for these VIs. When I need the tool tips, I set the position via VI server calls, then make a call to FP.Open(False, Standard).

Occasionally though, my tool-tips loose their "floatiness" (buoyancy? topness?). See the bottom part of the image below:

post-11742-0-44467300-1306511610_thumb.p

I end up with not so helpful tool-tips as they end up hiding behind the front panel they're acting as tool tips for.

Has Anyone seen this before? Anyone know what might be causing this behavior?

-m

By the way, I'll add that I have a work around wherein I call User32.dll:SetWindowPos each time I set the position of the tool-tip:

post-11742-0-75624400-1306512972_thumb.p

But this seems like something I shouldn't need to do since the VI's properties are set to floating. Even when the problem arises, the FP.Behavior property still returns Floating despite obviously not being floating...

Warning! Random conjecture ahead:

I have no idea what causes this, but I've finally narrowed down a reproducible case which triggers it (sorry, can't post the application online). Ultimately I have a situation like this.

1. My main VI is open. All is happy. Sunshine, lollipops, all that good stuff.

2. The user asks to open a new VI, which is a second independent VI running asynchronously. That VI does some Win32 wizardry to make itself look like a tooltip window:

post-11742-0-40903500-1306512509_thumb.p

(Those are calls to User32.dll:GetWindowLong and User32.dll:SetWindowLong).

3. I go and do something else in another application. For now, let's say I interact with my Chrome window so I can post on Lava.

4. I go back to my main VI. Move my mouse and my tool-tip window is now suddenly at the bottom of the z-stack. Darn.

Link to comment

New problem:

Using my method, the tool-tip does indeed come to the front of my application windows, but unfortunately brings every window from my application on top of other application windows when I make the call. Not a good thing, this means that inadvertently moving your mouse over an open window in my application will automatically bring it over all others if you happen to hit a hot spot.

The property node Ryan indicated is not ideal because it unfortunately applies focus to the tooltip window, making the main window's border flash quite annoyingly as the mouse moves on and off hot spots in the owning VI.

Back to the drawing board :(

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.