LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

Making a panel (splash screen) display as fast as possible

Our LabWindows 2017 program seems to have quite a delay before the splash screen appears. We load a TON of panels on startup, so I tried moving the splash screen display near the top:

    if (InitCVIRTE (ZERO, argv, ZERO) == ZERO) return NEG_ONE; // main()
//#endif
    
    // Load and display the splash screen as soon as possible.
    if ((g_PanelSplashScreen = LoadPanel (0,  "PanelSS.uir", PANEL_SS)) < ZERO) return NEG_ONE;
    // We need the SLOG panel for logging.
    if ((g_PanelSystemLog = LoadPanel (0, "PanelSLOG.uir", PANEL_SLOG)) < ZERO) return NEG_ONE;

    // Update version on Splash Screen panel.
    SetCtrlVal (g_PanelSplashScreen, PANEL_SS_VERSION, HOST_VERSION_STRING);
    SetCtrlVal (g_PanelSplashScreen, PANEL_SS_VERSION_I2C, i2cVerString);
    SetCtrlVal (g_PanelSplashScreen, PANEL_SS_VERSION_MSG, msgVerString);
    
    SetCtrlVal (g_PanelSplashScreen, PANEL_SS_STATUS, "Loading user interface...");
    DisplayPanel (g_PanelSplashScreen);

Should this display the panel then, or does this not take effect until after RunUserInterface() or something?

 

Thanks, much.

0 Kudos
Message 1 of 4
(202 Views)

RunUserInterface () is not required to display a panel on screen, it simply starts event processing.

Our programs too have a splash screen during startup, loaded and displayed as you are doing. You may try adding a ProcessDrawEvents () to force UI update, but it should not be necessary as of my experience.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
Message 2 of 4
(176 Views)

From the help description of SetCtrlVal:

 

Note   This function updates the displayed value immediately. Use SetCtrlAttribute with ATTR_CTRL_VAL to set the control value without immediately updating the displayed value. For this reason, SetCtrlAttribute with ATTR_CTRL_VAL is generally faster than SetCtrlVal. However, if the control in which you are setting the value is the active control in the panel, SetCtrlAttribute with ATTR_CTRL_VAL displays the value immediately.

 

So using SetCtrlAttribute() with ATTR_CTRL_VAL should be the fastest way of updating the controls without redrawing each time before displaying, if none of the controls are active by default.  If you have to update the active control, do it last so you only redraw once before displaying.  In my experience, this makes a huge difference with complex controls like tables, but may or may not be noticeable in your application.

Message 3 of 4
(164 Views)

Thank you both for these responses, and this is an interesting tip:


@Sporty wrote:

From the help description of SetCtrlVal:

 

Note   This function updates the displayed value immediately. Use SetCtrlAttribute with ATTR_CTRL_VAL to set the control value without immediately updating the displayed value. For this reason, SetCtrlAttribute with ATTR_CTRL_VAL is generally faster than SetCtrlVal. However, if the control in which you are setting the value is the active control in the panel, SetCtrlAttribute with ATTR_CTRL_VAL displays the value immediately.

 

So using SetCtrlAttribute() with ATTR_CTRL_VAL should be the fastest way of updating the controls without redrawing each time before displaying, if none of the controls are active by default.  If you have to update the active control, do it last so you only redraw once before displaying.  In my experience, this makes a huge difference with complex controls like tables, but may or may not be noticeable in your application.


I have moved my code around so the first thing it does is load the panel and display it, and that works. I traced my issue of "why has it gotten so slow" to a "Log Init" routine I wrote, which -- on startup -- will purge files older than 30 days. I had this at the top of the program since I want to be able to start logging as soon as possible. I've started and stopped my program so much in the past month (creating so many log files) that this code was the reason for the delay. "It always worked before" was because normally we don't have that many log files.


Scanning thru them seems slow.

 

Thank you all for your responses. Once I knew it "should" happen when I do the call, it let me focus on anything else that could be causing the delay.

0 Kudos
Message 4 of 4
(156 Views)