Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Saving UI state Collapse All
Subject Author Date
Offer Har Apr 14, 2011 - 6:43 AM

Hi,


We would like to save the state of the UI when it changed, and not when the application exits, so that if the application crashes or killed it will remember its state. Is there any way to do it without periodically saving the state? For example, is there any event that can be caught when the UI state is changed?


Thanks,


Ron.

Technical Support Apr 21, 2011 - 12:39 PM

If you have two control bars docked into one vertical column and state of top control bar should not be serialized, then how do we know the bottom control bar’s state should be restored and bottom bar should appear at the bottom side of the top bar? Ron, it’s not possible to serialize state of some bars only. We need to try to take a look at UI design in your app in some different way. Or, we need more details about your app.

Technical Support Apr 20, 2011 - 1:27 PM

1) Yes.

2) It’s not possible to avoid state saving for particular bars. The state of each bar always mutually depend on other bars. This is related for all control bar types. You can simply hide the bars which do not require user attention.

Technical Support Apr 14, 2011 - 1:48 PM

Thank you for the interesting question. Please create and use your own CExtControlBar-derived class which should override the CExtControlBar::OnControlBarPositionChange() virtual method to catch any layout changing. If the bFinal method parameter is true, then user has stopped changing control bar layout (dragging, double clicking, etc.) and you can save control bar state. You can save it immediately. You can also use some timer and flag to implement periodic state saving only when layout is really changed and not more often then some time interval. In the last case the overriden CExtControlBar::OnControlBarPositionChange() virtual method should only set flag value for further usage inside timer handler code. The timer handler should save control bar states only of there are no control bar drag-n-dropping is occurred at the timer event moment (CExtControlBar::_DraggingGetBar()).

Offer Har Apr 17, 2011 - 4:33 AM

Dear Support,


I did a test, and added the virtual function.


I see that for every control bar or toolbar I move, the function is invoked for ALL the control and tool bars in my system... this seems to be a lot of overhead over nothing - for example, if a control-bar is floating even on a different monitor, this happens - please check this, as it seems to be a bug.


Thanks,


Ron.

Offer Har Apr 17, 2011 - 4:05 AM

Dear Support,


Thank you for the detailed answer. Before I go and do it, there are two issues that we still need to clarify:


1. Will it work also with toolbars (CExtToolControlBar derived) - I think this is trivial...


2. We have some control-bars that we do not save their state - the way we currently do it, is that we close them when the application is about to exit, and this way their state is not saved. When changing the concept to the one we now want, we need some method of not serializing these controls to the state data - is there any way of doing this? This is a show-stopper for us...


Thanks,

Ron.

Offer Har Apr 20, 2011 - 1:44 PM

That’s a MAJOR problem for us.
Isn’t there a place where you iterate over all control-bar and save their state?
We cannot hide them, as it will flicker when we do it... as we want to do periodically.
Please help us solve this problem.

Technical Support Apr 21, 2011 - 5:16 AM

Mutual state dependency of each control bar on other control bars does not allow us to avoid flickering in 100% of cases. If we cannot solve something, then we should hide it from the user.

HWND hWndMainFrame = . . .
CRect rcSurface;
        ::GetWindowRect( hWndMainFrame, &rcSurface );
HWND hWndSurface =
            ::CreateWindowEx(
                0, _T("Static"), _T(""), WS_POPUP,
                rcSurface.left,
                rcSurface.top,
                rcSurface.Width()
                    + (        (    _wp.showCmd == SW_SHOWNORMAL
                            &&    g_PaintManager.m_bIsWinXPorLater
                            ) ? 1 : 0  // +1 for recomputing Window HRGN on WindowsXP or Later
                        ),
                rcSurface.Height(),
                hWndOwn, (HMENU)NULL, ::AfxGetInstanceHandle(), NULL
                );
        ASSERT( hWndSurface != NULL );
        ::EnableWindow( hWndSurface, FALSE );
        ::ShowWindow( hWndSurface, SW_SHOWNOACTIVATE );
//
// TO-DO: do anything you want with control bars inside main frame
//
        ::DestroyWindow( hWndSurface );
        CExtPaintManager::stat_PassPaintMessages();

Offer Har Apr 21, 2011 - 9:45 AM

We cannot have flickers for this task... this will kill our system.
Another suggestion - can we add some property to each control-bar if we want to load it - we will save it, but when the system will open and load its state, it will look for this flag, and if the control-bar is marked as no-load it will hide it.
This *might* flicker when the application loads, but this will flicker only once.
Is it possible to add this to the next version?
Thanks,
Ron