Repainting VI windows

[Oliver Friedrich]

Hallo LV'ers,

I'm running LV5.1.1. I have an application where I have a parent window
which stays the same all the time. Within this parent window I display
different child windows in a sequence. Each of the childs is docked to the
parent by means of some WinAPI functions like SetParent (I'm using the
G-Toolbox). It works fine. Now the problem: Every time a child is docked to
the parent, the entire parent window is repainted, even the parts of it
which are left unchanged. That causes the screen to flicker in a not very
nice way.
Is there a way to define the region of the parent window to be repainted, so
that only the region of the childs are repainted. I know of this commands in
the WinAPI, but how can I do this in LV ? Do I have t
o use WinAPI commands
to solve this problem?

Best thanks for your help!

Oliver Friedrich

[Christopher Mitchell]

There isn't a nifty utility in LabVIEW that will allow you to repaint only a portion of the front panel. If you know of the WinAPI command then you might try using it.

[x]

if you show your diagram, maybe I can find a way to solve this.
BTW, what platform are you working on?

George Zou
georgezou@163.com


"Oliver Friedrich" wrote in message
news:ZTt77.25770$B5.2998216@monolith.news.easynet.net...
> Hallo LV'ers,
>
> I'm running LV5.1.1. I have an application where I have a parent window
> which stays the same all the time. Within this parent window I display
> different child windows in a sequence. Each of the childs is docked to the
> parent by means of some WinAPI functions like SetParent (I'm using the
> G-Toolbox). It works fine. Now the problem: Every time a child is docked
to
> the parent, the entire parent window is repainted, even the parts of it
> which are left unchanged. That causes the screen to
flicker in a not very
> nice way.
> Is there a way to define the region of the parent window to be repainted,
so
> that only the region of the childs are repainted. I know of this commands
in
> the WinAPI, but how can I do this in LV ? Do I have to use WinAPI commands
> to solve this problem?
>
> Best thanks for your help!
>
> Oliver Friedrich
>
>

[Labviewguru]

Oliver,

My recommendation is to change your methodology. Get away from MS native functions. This will solve your problems, and make your program platform independent.

As an alternative, try calling the front panel either as visible using the server, or directly. Then you can set it to frontmost or dialog, as necessary, and even control it's location. This should (though I haven't researched it much) solve your problems. This also puts you back in the driver's seat instead of Microsoft. This is a good discipline to have, if you ever decide (or have it decided for you) to program outside of Microsoft.

[Oliver Friedrich]

Maybe the next time, I'll think about programming platform-independent.
I thought of your solution, but I've discarded it after considering a few
more constraints in my application.
1. I don't want the child window to be movable.
2. The child has neither menubar, nor frames or resizing or close buttons, I
want it not to be recognizable as a separate window.
3. I want to have the parent still capable of getting the focus.

So, there are quite some problems with modal windows. And further more, my
product requirement specifications tells me to develop for Win98, NT and so
on, so what ?

Anyway, thanks a lot for your help, I hope I can help you one of these days.

Best regards

Oliver
"Labviewguru" schrieb im Newsbeitrag
news:50650000000500000
00F390000-993342863000@exchange.ni.com...
> Oliver,
>
> My recommendation is to change your methodology. Get away from MS
> native functions. This will solve your problems, and make your
> program platform independent.
>
> As an alternative, try calling the front panel either as visible using
> the server, or directly. Then you can set it to frontmost or dialog,
> as necessary, and even control it's location. This should (though I
> haven't researched it much) solve your problems. This also puts you
> back in the driver's seat instead of Microsoft. This is a good
> discipline to have, if you ever decide (or have it decided for you) to
> program outside of Microsoft.