Is there any way to check if a control is blocked before acting on it? I'm having an issue automating a silverlight application. Certain controls in a table intermittently appear as blocked when playing back when other times they can be accessed. There does not seem to be any reason for the blockage because it works more often than not. I've tried adding wait statements, I've tried both hand coding the control reference and recording it, I've even tried accessing other parts of the cell and tried tabbing to the cell... it just occasionally appears to be blocked.
To make things trickier, the control only appears to be blocked during playback. If I run in debug mode, the control is always visible.
There are a number of WaitForControl... methods that may help. See also On Document Ready equivalent
Related
I'm updating a very large Windows Forms app to .Net Maui to make it into a cross platform app. Ideally, I would have the time to rewrite everything, but I don't. The client wants it yesterday. I'm already using a ton of the allotted time replacing the Windows Forms style interface with the XAML version. I've tried not to tinker too much with the code since the app was behaving flawlessly. Still, I've had to make a lot of changes because the Maui controls aren't always accessed the same ways as Windows Form's controls. Almost all of the methods and functions in the original app are synchronous. But some of the .Net Maui functions that I use to replace them are asynchronous. One function that is giving me a lot of trouble is the awaitable DisplayAlert(). Execution moves right onto the next statement in the code without waiting for the alert to be displayed or the user to respond. The function can be made awaitable, but to do this, the entire method within which it appears must be marked Async, which creates its own problems. There are literally hundreds of calls to The Windows Forms version of DisplayAlert(). Any solution that isn't basically a drop in replacement is going to cost tons of time.
I've been trying to create a blocking popup function that waits for the user's response before executing the next line of code within a synchronous block of code. In the XAML markup I've defined a popup "panel" with a frame, two labels and 3 buttons. Ideally, the code behind should be a function with the same parameters and behaviors as DisplayAlert() except that it blocks. It should display the panel, wait for a user response (button click/press), hide the panel, and finally return the text string of the button that was clicked...all within the same function.
Using simple method's like while loops to determine if a button was pressed block the thread from detecting that a button was press. Moving the panel display to a different thread than the button press, does nothing since the panel can only be displayed on the main thread. Invoking on the main thread has not been successful...at least not the way I wrote the code. I'm hoping someone can provide a very simple example of a blocking DisplayAlert() function that can be used within a non-async method.
I'm having an issue with WPF's WebBrowser control. It's crashing with the titular error when I'm changing tabs - I think I know why (explained below), but I can't think of a way around it. I'm looking for either ideas on how I might reorganize the code to work correctly, or alternatives on what I'm using to achieve my goal.
The setup of the program is this: There are multiple tabs, containing Borders/Grids/etc. On one of these tabs, there is a Grid which has "Widgets", each containing a WebBrowser. These browsers are loading various locally-hosted pages with information for the user. To make the widgets look good, some code runs in the LoadCompleted event of the browser.
brow = new WebBrowser();
brow.LoadCompleted += wb_LoadCompleted;
(The wb_LoadCompleted function isn't important: the program will crash as it's being called, not during its execution.)
Also, when the user changes tabs, these Widgets have a Dispose function that's called.
brow.LoadCompleted -= wb_LoadCompleted;
brow.Source = null;
Now if the user opens the tab with these Widgets, then after the pages begin loading, but before they finish loading and call that event, the user switches tabs again, the program will crash once it attempts to call the wb_LoadCompleted event. I think this is happening because of the error described here. The handlers have been disposed because the tab changed, but the thread wants to call the handlers. In Visual Studio, if I place a break on the wb_LoadCompleted method, it'll be on that breakpoint when the error is thrown, so I think the program still knows what code it should be running, it just doesn't have permission to.
So far I've been unable to find a workaround or solution. Beyond code fix attempts, I've tried using different browser controls (Awesemonium, and a few others); while they work without this error, but they also balloon the size of our program distribution by 30 meg. That nearly doubles the size, and it's not feasible for us to do so. Any alternative browser control that works would be great, but it needs to be ~10 meg max.
I can also share some other code if you let me know what you need to see; however, I'd imagine this is more of a timing/placement/ordering issue than current code issue, if that makes sense.
e; Adding the full error text:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in -programpath-
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x6bd5e4ad, on thread 0xa54. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
In any .NET 2.0 Winforms application, if you run the code in Debug Mode, and you either hit a breakpoint or otherwise Step Into the code line by line, and you want to see the GUI of the application being debugged, then .NET does not draw the application screen.
For example, I have an application which writes some messages to a TextBox on a Form. When I debug the code step by step, or when a breakpoint is hit, I want to see what all messages are logged in the TextBox, but if I press Alt-Tab to switch from VS2005 window to the WinForms application window, all I see is white color. The form is not redrawn, until you press F5 in the debug mode in VS2005.
What is the reason for this, and is there a way to overcome this, without introducing any threads in the code?
What is the reason for this
While you're debugging, you're effectively blocking the UI thread - you're manually stepping through its execution flow. The UI thread can't draw the UI while you're stopping it from executing.
and is there a way to overcome this
You could try calling Application.DoEvents() manually, but I'd generally recommend against it.
It would be better to just wait until you got to the end of the method and let the UI redraw itself normally. If your method is very long (in terms of time) then bear in mind that when not debugging, the UI still wouldn't be able to update itself while that method is executing. This may cause you to change your design (it's hard to tell just from the information we've got at the moment).
The reason for this is because you can only have one UI thread, and when you enter your method that updates that code that code begins blocking the UI thread. It will not update until your method exits.
Here is a good SO on message pumps, which are what drive the UI updates
You should be able to use Add Watch/Quick Watch to look at any values at the time of debugging. This sounds like what you are really looking for, anyway.
Like everyone else has said in answers and comments, the UI thread is blocked so it cannot be redrawn.
However, if all you want to do is see the GUI, and not interact with it, and you are running Windows 7/8 (which sounds unlikely since you're using VS2005) and haven't disabled aero peek, you can mouse over your application in the task bar and Windows will show the preview thumbnail. When you mouse over the thumbnail, you can "peek" at the application even when the breakpoint is blocking the UI thread.
In vb6 you could see a textbox update immediately when the value was changed, but I've noticed in .net that it will not update until after the method you are in has been exited. A preliminary question I have is whether there is a way to make the textbox update before the method is completed.
The issue is that I have two textboxes whose Text properties are set and when the method completes, only one of them consistently updates on screen. The other usually does not, but sometimes does. It's very sporadic. I literally called someone over to verify I wasn't taking crazy pills and of course it started working when she came over (though I made no code changes). Then when the QA guy came around it stopped working again (again, didn't make any code changes).
All I've been doing is setting break points and stepping through code trying to figure out what's keeping this text box from being updated. At the end of the procedure, right before it exits, I can check on the Text property and it has the correct value, but as soon as the method finishes it disappears.
I will try to get a code snippet up soon, but in the meantime I would love to know if anyone else has had this problem and any good ideas on how to debug b/c I'm getting a bit frustrated! There is a timer on the form that is enabled at a certain point and disables itself when it's run... setting a breakpoint in this timer verifies that it is not the culprit b/c the breakpoint never gets hit. But I am wondering if there could be some other asynchronous process I might be missing... I don't think so but if you can tell me anything I should be looking for that I might not have thought of please do.
Edit: I would post a code snippet, but the snippet I wanted to post doesn't reproduce the problem and I have not isolated the problem to a small enough section of code for it to be practical to post. I will add a little more info though:
After the method that updates these textboxes is completed, control returns to the form. There are no other processes going on. I kept thinking maybe some code was getting run somewhere that was blanking out the textbox but a thorough look through the code has confirmed this is definitely not the case... when the method completes nothing else happens.
I noticed when I was debugging that sometimes it would work properly, and on a rare occasion it would even work properly when running normally. I added a DoEvents() to see if it would work and it did the first time... but then did not continue to work. Out of frustration I added repeated calls to set the textbox and DoEvents() after each one and that did not make it perfect. Lastly I added a call for the thread to Sleep() for 300 milliseconds and it seems to be better now.
Keep in mind that there is another almost identical textbox on the form that gets set in the same procedure and never has any problem updating whatsoever. I have searched for any difference between the two controls and aside from size, location, and name I cannot find any difference.
I suppose you could add: Application.DoEvents() after you set the textbox text value. Its usually frowned upon to use DoEvents, though it may solve your issue in the intermediate.
i think you better use Invalidate(); this will cause control to redraw yourtextbox.Invalidate();
you can use Threading for this purpose
I'm writing a c# application that requires user authentication.
When the user hits the log in button, quite a bit of stuff is done in the background, but I'm having trouble informing the user that something is happening, and that the program isn't just frozen.
I have some hidden text fields that I would like to have show up after they log in, while this stuff is running, but I can't seem to get it to show up.
Basically, when the user hits the log in button, it checks to see if their credentials are correct, then the messages should show up, and then either some other functions might run, followed by a different form being shown.
After the credentials are checked, and I know that the user is valid, I tried running this:
please_wait.Visible = true;
But it doesn't change when it gets to that point in the code.
I've tried threading it, to see if that would help. Instead of calling the above line, I just start a thread that does it.
That doesn't work either. The field still doesn't show up.
If I return out of the function right after I either start the thread or change the Visible property, it works just fine.
How do I get it to work fine and have more code run after the change?
The problem isn't that you need to update the UI from a background thread. Rather, it's that you should be performing your long-running task in a background thread and marshalling updates to the foreground. This is frequently done via a BackgroundWorker with progress notification (on a progressbar, for example).
Basically, your UI foreground thread is either loaded or blocked doing work, so it isn't handling messages in its message queue to update your user interface.
Along with what Greg recommends (which is certainly the first step if you're not already doing it) you may also need to give up some quantum.
If you are taxing the scheduler, it's possible that the UI updates (which are pretty low priority) may be getting preempted until your worker is complete. Adding an Application.DoEvents (or maybe Thread.Sleep(1) in the background thread) could give the UI a little scheduler time to paint.
Have you tried adding a call to Application.DoEvents()? It's a hack, but it's all you sometimes need.