I have a tool that starts and stops services. When a service is being started, I want to show a form that simply shows "Please wait while the service starts". I created a form that has a label and a progress bar in marquee-mode. When that form is shown, I want the main form to be blocked. So I called the please wait form with .ShowDialog. But of course, that stops the main form until the please wait dialog is closed. So I simply used .Show for the please-wait-dialog. So I call this:
PleaseWaitDialog.Show()
service.Start()
service.WaitForStatus(ServiceControllerStatus.Running)
PleaseWaitDialog.Dispose()
However, the PleaseWait dialog is shown but the waiting for the service to start stops the whole GUI so that the progress bar won't show the marquee.
How can I show the PleaseWait-dialog and make the progress bar do the marquee but also keep the program running and waiting for the service to start? I guess it has something to do with multi threading but I am not very familiar with that.
I tried using .ShowDialog which let's the GUI on the please wait form do its thing but that of course stops all other things that should be done while that dialog is shown
Related
When I press a button in VC++, the program starts reading data from USB which takes several minutes to be completed. During this operation I want to show the status of the progress in an edit box in the same Dialog using m_editCtrl.SetWindowTextW(output1); But during the transfer the contents of the Edit box are not changed. How can we change it?
Thanks
If the main thread is busy like in a loop, it will not update GUI. You should create a thread which does the heavy lifting and the thread, in turn, should post update messages to GUI.
Here is an example to get started and will do the job but it can be improved. In this example, the thread is calling the GUI API directly but it will be even better if you post a message to parent window using HWND and it will update itself.
We have a Form that is shown as a Dialogue above the main Form.
DialogResult rslt = cvForm.ShowDialog();
In Coded UI test, immediately when the Dialogue is lunched, the Mouse.Click tries to close it by clicking the "x" button of the Form.
However, seems the x button cannot respond the click event sometimes, on a certain machine it always fails to close the Form unless we put a wait before the click.
All WaitForControlxxx() does not serve as wait because they immediately returns.
Only putting PlayWait(1000) before the click works and can close the Form.
And the failure only happens on our lab machine. On my laptop, even without PlayWait(1000), it works fine.
Seems it's only a timing issue.
Is there anything I can wait for instead of blindly wait for 1 second in order for it to work on the lab machine?
//this.UIAUDIO_TX_HPF_IIRWindow refers to the Form shown as a Dialogue:
// this.UIAUDIO_TX_HPF_IIRWindow
//ulCloseButton refers to the "x" button on the Form:
WinButton uICloseButton = this.UIAUDIO_TX_HPF_IIRWindow.UIAUDIO_TX_HPF_IIRTitleBar.UICloseButton;
The following code cannot close the WinForm window on our lab machine, but CAN close it on my laptop machine:
uICloseButton.WaitForControlExist();
uICloseButton.WaitForControlReady();
uICloseButton.WaitForControlEnabled();
this.UIAUDIO_TX_HPF_IIRWindow.WaitForControlReady();
//Mouse.Click(uICloseButton, new Point(15, 9));
Mouse.Click(uICloseButton);
The following code CAN close the WinForm window on our lab machine:
Playback.Wait(1000);
Mouse.Click(uICloseButton);
Any comments?
It seems dialog is not completely ready to change focus on dialog.
Before focus gets ready, test is trying to close it.
Try with following code.
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
Here WaitForReadyLevel.UIThreads option also present.
This will increase test execution time.
Actually, I want to store some data in background page and the popup page just show that part of data say Data as a div element created in background page document.createElement("div"). Here, the background page will register some listeners to the tab update and change the Data elements accordingly. What the popup will do is to get that Data and appendit use the document.appendChild(Data).
(The purpose I intend is this will cause the popup changes immediately while the tab updage is triggered.)
However, the elements are shown as usual, what I am facing very headache is I have registered the onclick for the div object in backgroundpage as onclick="chrome.extension.getBackgroundPage().somefunc()". However, the first time, all the click will triger the right behavior but after the popup loses foucs and get focus again, all the click won't work.
I try to put something like change the onclick="somefunc()" and leave the func within the script of popup page. And there I want to log whether it is called by console.log("clicked"). Here, something unbelievable happens, the function is succefully trigerred BUT the console is null here, I cannot even call chrome.extension.getBackgroundPage() as well.
Here are a list of questions, maybe very hard to express for me...
1. Whether I can reuse the DOM element from the background page to the popup page directly by appendChild(chrome.extension.getBackgroundPage().getElementById()?
2.Will the onclick event registered in the background page still work in the popup pages?
3. What's the problem with the problem I am encountering? I have tried many ways to find out the reason but all in vain at last...
Best Regards,
If you need any more information, please let me know.
(PS: I am wonderning if it is called something like the event propogation, however, I am not an expert in this two pages communicating...)
Is there any way of showing Wait Screen, while some processing is done in backend, using LWUIT in J2ME ? if yes then how if no then is there any alternate ?
You can look at progress bar with LWUIT. Sample Wait screen used in the makeover demo and the browser demo application in current LWUIT Repository. Also see here.
I had this issue as well, but got a workaround: these suggestions here seemed not to be the best for me. The dialog when it displays will block any other action except it is discarded, even if it was created with no commands.
What I did was to add a wait screen to the BorderLayout.CENTER of the main container or the Form, then when the thread running my background task finishes, the component is now replaced with the loaded component.
I dont know if anyone would find this useful since this has already been answered. I just felt like posting my own trick.
You can start a thread in which you do your stuff of getting data and all and in the UI thread show the loading dialog and then dispose that loading dialog once you are done with your services call.
I am coding up a program for automated testing which randomly clicks an open application window using various User32.dll library calls. My current problem is this, if a click would open a dialog, using Process.WaitForInputIdle() does not wait long enough for that dialog to be detected the next trip around the loop, which means several clicks get cued and if those clicks happen to be on something in the dialog I want to avoid (say an exit button) there is no way of telling that in advance. My question is this. Is there a way of waiting for the process or thread to finish all processing and only be waiting in the message loop again?
I hope that made sense.
Cheers
Ross
EDIT
Failing this, would it be somehow possible to set the process / threads of the target program and my program to both use the same processor and adjust the prioritorys of each so that the target program gets preference?
WaitForInputIdle will unfortunately return as soon as the app is in a message loop with no input messages waiting.
If you own the code to the dialog, you could have the dialog call SetEvent in its WM_INITDIALOG to signal your automation that it is ready for testing. Alternatively, you could look at using SetWinEventHook on the process and wait for the dialog to actually be created before sending input events to it.
The way around this it seems is to use the SendMessage API instead of the mouse_event or SendInput API. The reason for this is that SendMessage blocks until it has been processed. Just make sure you always get the handle of the window immediatly under where you want to click (using WindowFromPoint) and convert the mouse coordinates from screen to client coords using ScreenToClient. Pack the coordinates into the lParam parameter by using ((pt.Y << 16) + pt.X). This will block until processed and so any modal dialogs shown will block this call.