Search the Community
Showing results for tags 'ui thread'.
Hello Lavag's, Currently developing an UI with custom titlebar like JKI Package Manager 2020, applications from MS Office etc. I have a laptop (1440 X 900) running windows 7 and a second monitor with resolution 1920 X 1080. Scale and layout options for both monitors are set to 100%. "FP.State = Maximized" seems to work only when the resolutions for all monitors are equal or selecting the monitor with highest resolution as main screen. 1. Laptop(1440 X 900) as main screen: FP.State = Maximized works fine in Laptop but not in second monitor. The Panel Bounds and Window Bounds are way out of the screen resolution. Same as in case of JKI VI Package Manager (2020) 2. Setting Window bounds and panel bounds manually: Some pixels appear in the another monitor when setting the Window Bounds and Panel Bounds manually. This sems to be also the case with NI-Package Manager Is there a way to make it work? Any help is greatly appreciated. Regards, Nikhil. Custom Titlebar.vi
I have been working on an architecture that uses VI Server to send messages between application instances, both local and across the network. One of the problems I have run into is the fact that VI Server calls are blocked by activity in the root loop (sometimes referred to as the UI Thread). There are several things that can cause this: other VI server calls, system dialogs (calls to the one and two button dialog functions), if the user drops down a menu but does not make a selection... (I'm sure there are more...) Since this is a pretty normal way of communicating between applications, I was wondering if anyone had any ideas for a work around. Here is a basic description of my architecture: Message is created and sent to local VI that sends to outside application instance. Local sending VI opens VI server connection to remote instance. It then calls a VI in the remote instance that takes the message as input. This remote VI them places the message in the appropriate queue on the remote instance so it gets handled. If the remote instance root loop is blocked, the sending VI on the local machine is also blocked. I could try to eliminate all system dialogs from the remote application, but that only partially addresses the issue. I really wish a future version of LabVIEW would eliminate this problem with the root loop and VI Server all together. BTW: using LV2012 but this issue exists in all versions. -John