LabVIEW
Child vi cannot disappear when parent vi rolling up
@coloredsound wrote:
Hello Carya,
I am sorry but technically speaking my question yet been answered, but i will give kudo for useful comment
The question hasn't been answered (it's because LV uses windows client area to draw in. So LV's FP is smaller then Windows client area). But the problem is solved, right? It's not accept as answered, but accept as solution.
Problem with not marking (your own summary) as accept solution, that it shows up as unsolved. People will spend energy in trying to help, only to find out it's not needed.
Also, you will get an angry (not) email from NI after 2 weeks ;).
Search LabVIEW like a graph!
I will close the question if there is still no solution, i will accept what i think is appropriate, thank you
What part of you're problem is not solved?
Lets go back to your original question... Not trying to put wood on the fire, just trying to help.
Feel free to skip this (off topic) background:
So when using Windows API to make a front panel a child window, LabVIEW will simply ignore this. The window is a MS window (on windows), but LabVIEW manages it. LabVIEW is rather unique that way, in that you are in a way changing the IDE (VI's front panel) from code. LabVIEW simply ignores the fact that you've changed a window setting. Some things are handled by windows, but other things are done by LabVIEW. They will bite each other. One thing you have to battle is that LabVIEW might decide to put the FP in a new hWindow at will (typically when the VI is closed\hidden and reopened).
Many of us (including myself) tried to make this work (before subpanels existed). I don't think many of us fully succeeded. The exact behaviour might change between LV versions as well.
One of the reasons (or the reason) is that LabVIEW is multi-platform. LabVIEW is made to behave well on a few platforms, but it's way more difficult to support all features of those platforms, if that makes sense.
There are workarounds other then the SubPanel method. They might solve the problem, but indeed do not answer the question. Just let us know if you're interested...
Back to the original question:
You might have better luck if you use FP.Panel Bounds or FP.Window Bounds instead of FP.Run-Time Position.Custom. The latter will only set the FP position once when the VI is first run. If it's already running it is ignored (until the next run). Not sure if it is the problem, but in general it will function better.
Another think to consider is the Pane's origin. I haven't seen enough of you're code to know for sure if that is a problem. When you move the scrollbar, the pane's origin moves. However, the child's position as far as MS is concerned is relative to the main VI's panel coordinates. This is typically hard to get exactly right.
The clipping at the top of the window should be the same as the bottom. At least when the toolbar is hidden. Are you sure it's not an error in the position you move it to? Without code to reproduce it, it will be hard to solve this.
@coloredsound wrote:
Hello Carya,
what do you mean by this?
as far as i know, you can set vi window as child window of another another vi window using user32dll as shown in my last video
Of course you can, but you are doing something LabVIEW is not designed to support.They have the subpanel specifically for that. There may be rules about how windows handling should work in order to be used seemlessly as child windows in another window. But the whole LabVIEW windowing code to do this was developed back about 30 years ago, when Windows 3.1 was just barely out, at a time where child windows were something that only Windows used for its control widgets and which only worked if you did jump through every of the 200 hoops Microsoft had created to make this beast work. LabVIEW as a multiplatform application added to those 200 hoops in windows message handling a handful of its own to make the window management work on all platforms in a similar way.
When you investigate further you will notice that a LabVIEW window is really a fully custom drawn window which even does much of the menu handling itself. All the controls on the front panel are not OS widgets but fully custom drawn objects all handled by LabVIEW itself.
To make this all work they had to hack a few things that traditionally are hard to tackle since the different events can cause a whole avalanche of resulting events that all can come back and try to change things that earlier events have changed. So if you add child windows to that mix which can cause events send to parent windows whenever certain things happen you are very likely to create competing events to be caused that LabVIEW was never designed to handle. Could it be made to handle that all? Possibly, but the effort to do that would be enormous, very time consuming and there is a serious chance that it can't really be fully remedied without rewriting the entire window management code which is a major piece of the LabVIEW core and likely is a 5 man year project in its own. That all for the benefit of a few users wanting to circumvent subpanels by using the Windows only child window mechanisme and you see immediately that you don't need to be a bean counter to ban such a project to the round archive folder.
