LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Windows reshuffling

Solved!
Go to solution

I'm currently running LabVIEW on virtual machines, and i get constant reshuffling of my LV windows, causing me to lose track of the active VI. When saving or at random times when the project desides it needs to refresh some VI due to some quantum fluctuation everything reshuffles. My previously active VI usually lands somewhere in the middle. If i click or press e.g. ctrl+e while it's shuffling i have no idea or which window will actually recieve and activate the command. Often the ctrl+e ends up in the project window and the mouse click in the window that afterwards ends up at top, even though that was not the window i was clicking in.

Alt-tab or alt-tab+mouseclick is in no way guaranteed to get my window back, i usually have to try it 3 times before the correct VI appears. Often the selection process itself triggers a new shuffle.

If i remember the name of the VI i was looking at (i'm fixing an old program) i can get to the right VI through the VI list (ctrl+shift+w) (which leaves some wishes of it's own, like why can't i change the tab order to VI name is first tab)

I thought i found a good way to look through the VI's by ctrl-tab, but it seems to reshuffle midway through. It can be seen as i suppose i should be tabbing through all windows in order, but i get patterns as: A, B, C, D, E, C, D, F, G, H, B.

Have any of you had this issue? Tips, trix, fixes? Is it VMWare? The virtual graphics driver? LV?

I don't dare estimate how much time this has cost me, but is many % each day.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 1 of 12
(3,890 Views)

This is fairly common, although what I'm familiar with isn't what you're describing. The way this usually happens (and I heard this from others as well) is that LV gets stuck in some operation for a bit (so if you click the window you will get the not responding state) and when it comes out of it it recalculates the order of the windows and messes it up.

 

This doesn't happen during normal operation (only when LV gets stuck) and isn't as common as you seem to indicate it is in your case, so maybe it's something different. If it is the same thing, maybe it's possible to change it by setting how long it takes before Windows decides a program is "not responding"? I would suggest looking up if that's something you can set.


___________________
Try to take over the world!
0 Kudos
Message 2 of 12
(3,878 Views)

Happens to me too - it's pretty frustrating, especially when I have a lot of windows open. tst is right that it only seems to happen when LabVIEW 'hangs' for a moment. If I remember correctly, LabVIEW has its own window manager - which is why its windows don't always behave like Windows windows.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 3 of 12
(3,866 Views)

Running a Virtual machine for an external USB-drive doesn't help speed, but they dont fit on the internal drive.

Do you have any fix/workaround/tips?

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 12
(3,856 Views)
Solution
Accepted by Yamaeda

It doesn't matter what version or environment you are in, in my experience.

 

This seems to happen as projects grow larger.

 

Some tips that may help:

 

1. Work in the main instance and not in a project. As projects go large, some different weird things can happen when you work from a project instance. Alternatively try to break down a project into smaller sub-projects.

 

2. Have fewer VIs open Smiley Wink

 

3. Just guessing this might help: Keep your files compiled (no asterisks) or separate compiled code in all/most of your files.

 

 

//Thomas

Certified LabVIEW Architect
Message 5 of 12
(3,842 Views)

You're onto something Thols! I shut down the project file and opened the main VI, i've had no reshuffle so far! I'll try separating the code and see if that makes it possible to run with a project file. So it seems the project environment is the evil demon in this case!

I'll try some more, but working without a project is a decent workaround.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 6 of 12
(3,826 Views)

This problem of random window shuffling is still present in LabVIEW 2017. So it should have been fixed long time ago.

I totally disagree that it is a viable solution to work outside a project environment to work around this problem. The project is there to help the user not burden him or her!

Any prospects of fixing this?

0 Kudos
Message 7 of 12
(3,165 Views)

I am not sure if there will be a "fix" at all. The problem i see is that the issue is coupled closely with Windows.

Working in Windows with multiple applications, it happens from time to time that the order of applications in the taskbar get reordered. It seems that this is connected to application refresh or maybe restart due to error conditions or other update situations.

Also i've seen the reshuffling for instance in multiple Internet Explorer windows if one site generated an errror in a script. As a result, the order of the web pages opened in the different windows reshuffles.

The issue is not limited to LV. As tholt pointed out, recompilation (asterics at VI name) could greatly impact the behavior.

 

I personally try to have at maximum about 4 VIs open (seldom more). When debugging/developing in a deep nested subVI, i either open it directly from the project window or go into it with Ctrl+double click on subVIs until i reach the subVI i want to review. I tend to close all "intermediate" files as soon as possible.

I never conciously encountered reshuffling of VI windows.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 8 of 12
(3,160 Views)

Thank,s Norbert for your reply.
Although you may be right that it is a bug/feature of Windows, i am not convinced by the argument that other programs have similar behavior - maybe these programs have same incorrect Windows management.
I think a formal analysis of the problem is necessary.

 

0 Kudos
Message 9 of 12
(3,152 Views)

This is really severe.

I'm currently experiencing this with 11 LV windows (5x FP+BD, 1 project)

The project is indeed rather big.

 

The aggravating thing about this is that commands made just before the shuffle get executed in the new active window.

For example if I press Ctrl-R to run a vi, LV may "take a moment" causing it (or Windows) to shuffle windows - after that it runs the vi that happened to land on top.

This is possibly disasterous!

 

Yay for a formal analysis.

 

Version 16.02f 32 bit on Win7 64 bit.

0 Kudos
Message 10 of 12
(3,096 Views)