Disable the entire UI.. Prevent user to enter the inputs ???

[LOOSER_007]

Hi,

I have developed an application, containing some edit boxes, check boxes, radio buttons etc to get the inputs from the user.... after selecting desired inputs and filling up the edit boxes... user need to "click" a button.... At this moment i am creating a thread to perform some operation... so i want the UI to be diabled for the user becoz i am using the input data from the UI which should not be changed during the operation... after completing the operation in the thread.. i want to resume previous state of the UI....!!!

How can i do this...???

Can i use "PreTranslateMessage" to trap mouse button click so as to ignore it while the thread is running...!!!! Any Suggestions... Plz....

[Skizmo]

Disable the entire window with EnableWindow (false);

[LOOSER_007]

I tried that but doing so makes the window non-movable... i.e. i can't even drag the application window... also the System menu buttons like... "mininize, maximize and close" dosen't work when the window is disabled.... !!!!!

[Skizmo]

That is correct. What you could do is disable all children of the mainwindow. With GetWindow (GW_CHILD) you get the first child window of you mainwindow and with GetWindow (GW_HWNDNEXT) you can get the rest.

[Lindley]

Personally I'd change the design so that once the user clicks the button, the current values are pulled from all fields immediately and handed off to the thread as a unit. This way, there's no possibility of changes the user makes to the fields causing problems. Plus, trying to access GUI elements (such as data fields) from a secondary thread can cause its own share of issues anyway.

If you need to ensure that the user doesn't launch two dozen processing threads at once, you could disable the "go" button only while processing is underway.....

[Arjay]

This isn't too difficult if you let the MFC DDX mechanism help you.

Just create a control variable for each of the controls you wish to manage. You do this by selecting the control in the resource editor, right click and choose 'add variable'.

Next, write a private method to enable/disable these controls.

 
void EnableControls( BOOL bEnable )
{
  m_btnGo.EnableWindow( bEnable );
  m_ctlNameFirst.EnableWindow( bEnable );
  m_ctlNameLast.EnableWindow( bEnable );
 
  /*
   * add other controls
   */
 
}

Then, you simply call this method passing FALSE prior to creating the thread. When the thread finishes, have a thread posting a user defined UDM_THREAD_COMPLETED message back to the UI thread, intercept the message in the main thread, and reenable the controls when receiving the message.

As far as the data, I agree with Lindley. It's bad practice to have the thread read (or write) any data to the threads. If you need to pass data to the thread, you'll need to synchronize access to the data. On way to do this is to extract the data from the controls, put it into a struct and pass the struct to your thread. When you receive the UDM_THREAD_COMPLETED event, you can read the data back out of the structure and repopulate the controls.

Reading the data from and writing the data to the controls is a job for MFC and the DDX mechanism. You can make variables for each control that binds the control to the data variable. Again, select the control in the resource editor, right click and choose 'add variable'. This time change the 'category type' to 'Value', choose the variable type (CString, int, BOOL, etc.), name the variable and click OK. Do this for all the variables.

Now when you press the go button, you call UpdateData( ) and transfer the data from the variables to the structure and start your thread. When you receive the UDM_THREAD_COMPLETED message, you transfer the data from the struct back into the variables, then call UpdateData( FALSE ).

Btw, if you are familar with the DDX mechanism, you can point the DDX entries to the struct members directly and forego the 'extra' member variables. Of course this is an advanced technique and not to be used by users of GetDlgItem.

[LOOSER_007]

Thanks to all of you guys.... those suggestions were really helpful...

BTW actually what i am doing in my app is when the user click the "go" button... im creating a thread to establish the connection with the server and calling "connect" for some timeout value repeatedly...
If i dont create the thread, connect call just hangs up the application and the windows shows as "not responding" hence i created a thread to establish the connection... when established a user msg is posted to my main window... to process further on the same socket connection...!!!
After that only i read the data from the UI... That is why i dont want the user to change the inputs when the connection is being established....

Any suggestion on this... !!!

Thanks,

[hoxsiew]

In that sort of situation, I would launch a modal dialog with just a marquee progress bar and maybe a static "connecting" message and from this dialog spawn the connect thread and wait for the connection. The main window is blocked from user interaction, but still receives paint messages, etc. and the user knows that the app is doing something because the marquee bar is showing activity. When the thread exits with successful connection, end the dialog.

[Arjay]

Thanks to all of you guys.... those suggestions were really helpful...

BTW actually what i am doing in my app is when the user click the "go" button... im creating a thread to establish the connection with the server and calling "connect" for some timeout value repeatedly...
If i dont create the thread, connect call just hangs up the application and the windows shows as "not responding" hence i created a thread to establish the connection... when established a user msg is posted to my main window... to process further on the same socket connection...!!!
After that only i read the data from the UI... That is why i dont want the user to change the inputs when the connection is being established....

Any suggestion on this... !!!

Thanks,

Yeah, the suggestion is to disable the controls as I've outlined earlier. If you don't understand what I've layed out previously, then please ask.