Develop Reference

Off screen element teststack white

I need to automate 3rd party WPF application. I use
TestStack/White. This application has menu bar that is presented by images. After some actions menu is changing. There presents new images. When I want to click on new image:
Window mainWindow = application.GetWindow("Main window", InitializeOption.NoCache);
Image newTask = mainWindow.Get<Image>(SearchCriteria.ByControlType(ControlType.Image).AndIndex(2));
newTask.Click();
I get exception:
TestStack.White.AutomationException: Cannot perform action on Image.
AutomationId:, Name:, ControlType:image, FrameworkId:WPF, element is
offscreen.
I use Microsoft Inspect for research elements.
When I start tests, Inspect show me that image is offscreen. But if I do these actions manually, it works perfectly and in Inspect this image is not offscreen.
How can I refresh these elements or clear cache of window?

There are ReInitialize and ReloadIfCached methods on Window object. Try those to see if something changes.
Are you sure AndIndex(2) is correct element in that particular situation?
Try using GetMultiple and iterate the collection to see what images you actually have and which are not Offscreen.
WPF automation with White is pretty hard. Try Telerik Testing Framework and White could be supporting framework. It is much more easier that way.

It can be a problem with focus, try to use this before getting image:
mainWindow.Focus(DisplayState.Maximized);

Not an exact answer but the final solution I've got after all these TestStack.White not found elements, table rows, and so on. I started to move it to FlaUI. If something does not work or unstable with White then most likely I can get more stable and fast-executable FlaUI solution.
Fortunatly, such migration can be done with little steps. For example I already have TestStack.White.Application app, then I replace White portion of code with FlaUI like this:
var flApp = FlaUI.Core.Application.Attach(app.Process.Id);
using (var automation = new UIA3Automation())
{
// .. new UI element processing
}

I don’t think that caching is the problem here. You are getting the mainWindow with InitializeOption.NoCache. In Non-cache mode the controls are found on demand. So I presume that the cache is refreshed automatically. (https://github.com/TestStack/White/blob/master/src/TestStack.White/Factory/InitializeOption.cs)
Perhaps the index of the element you want to click is not 2.
Have you tried adding an explicit wait? It sounds like you have only tried adding an implicit wait.(https://github.com/TestStack/TestStack.docs/blob/master/_source/White/Advanced%20Topics/Waiting.md)

Winform has Red X exception

I am using a 3rd party control (ComponentOne) and at intermittently I would get this typical red X box such as this typical image shows. At first I thought I have a GDI leak, so after doing some leg works I verified my GDI numbers are fine when drawing controls.
After Googling around I found that this kind of error happens on the OnPaint() event and therefore even if i put a try and catch when calling the control to Render, it wont catch it.
So my next step is to have the following override in my code.
protected override void OnPaint(PaintEventArgs e)
{
try
{
base.OnPaint(e);
}
catch (Exception ex)
{
this.Invalidate(); //attempt to redraw the control
XmSam.Log(ex);
}
}
I think that should do the trick but I can't recreate this problem all the time and so I haven't been able to fully test the above code yet. My question is, if I render my control and it has exception then this code will attempt to redraw the control. Will this stuck in an indefinite loop and freezes my UI? or would you think whatever caused the exception will go away and upon the second control redraw and it should render fine?

I think that should do the trick
No, you made it far worse. Now your OnPaint() method is running over and over again, probably falling over on the same exception repeatedly. You'll see your program burning 100% core as well.
Getting an exception in OnPaint() is not something you can really survive. There's nothing to look at for the user, that's a guaranteed support call. Instead of hiding the problem, use the exception to figure out what actually went wrong and fix the problem. Use Debug + Exceptions, tick the Thrown checkbox for CLR exceptions so the debugger will stop when the exception is raised. Just in case, it is not unlikely that the exception is raised in framework code, also use Tools + Options, Debugging and untick the "Enable Just My Code" option.

When I have seen this in the past it always had to do with a threading issue. Are you updating this control from a different thread than the UI thread?
Its been a while since I've dealt with that but I think the easiest thing to do is use the BackGroundWorker Class to perform background operations and update form controls.
BackGroundWorker Class

AccessViolationException when interacting with RichTextBox

I'm aware there is a bug with .Net 2.0 with LCG which generates AccessViolationException when certain IEnumerable<> and similar objects are used; and that there is a hotfix.
I have a project in .Net 4.0 using WinForms running on Windows 7 x64. I have a very simple form - nothing but a form and a RichTextBox docked to take up the whole client size.
From a background thread, I periodically call an update method on my form that does something similar to the following:
public static void Log(string text)
{
Invoke((MethodInvoker)(() => {
lock(richTextBox) {
richTextBox.Text += text;
}
}));
}
I do actually have both the inside of the invoke and the outside in a try/catch (Yes, I know this is horrible!) and I'm doing some additional things like putting the caret to the end and scrolling to it. I'm also using StringBuilder but this is all beside the point:
Rarely, but inevitably, while debugging, my IDE detects an AccessViolationException somewhere in the code that's updating the text box. It's sometimes in the bit that updates the text, it's sometimes at the bit that makes the selection, and it's sometimes at the bit that scrolls to the caret. If I press F5 to continue, I usually don't see the problem for some time and the application continues as before.
There is nothing fancy happening with this text box. There is no race condition (first of all because I have a lock), but also because there is simply nothing in my code that would try and write to the text box at the same time as something else is trying to.
Any idea why this may be happening? I'm sorry, I don't know what other information I can put here, as I'm not even sure why this is happening in the first place.

Not sure what the rest of your code is doing but I reckon the problem is with lock(richTextBox). If the GUI thread is doing something with the RichTextBox, the lock will not work Or if you are accessing this RichTextBox in some other thread.

Custom Message Box That Blocks

How can I re-implement a modal message box in WP7.1 to display custom design?
I saw number of questions with answers, both here on SO and on the Internets as well.
However, all the solutions I saw so far was non-blocking. In my app, I sometimes use message boxes to confirm something, so I need the solution that blocks the UI thread just like the system-provided MessageBox class, i.e.
if( CustomMessageBox.confirm( "orly?" ) ) { ...
Update: decompiling System.Windows.dll from the simulator image revealed that MessageBox class is merely a thin wrapper around MessageBox_ShowCore in agcore.dll, which apparently calls MessageBoxW from coredll.dll..

You can use the Popup to design your own messagebox. Just like #MengMeng mentioned above, you can dive into the source code of the MessagePrompt in coding4Fun, then you can fnd out how to implement it.

Problem changing values in textbox

Simplifying
I have a text box and a button
The button just create an messagebox with the text from the textbox.
But i change the value of the textbox, the new value apears (Ex: Type 123) but the message box does not show the value.
If i try to use the value in the programming (get the value by textbox1.text) the variable has nothing ( textbox1.text = "") but i can still see what i typed in the form.
Anyone has any clue?

Your button's click event handler should look something like this
private void button_Click(object sender, EventArgs e)
{
MessageBox.Show(textBox.Text);
}
I suspect you already have code similar to this and that at some point the textbox is cleared or otherwise set to String.Emppty but without seeing actual code it is difficult to help you

When/where did you check the value of textBox1.Text? If you're checking it in the constructor, Form1_Load, or anything else that occurs before you'll have typed text, you will get an empty value.
To properly check the value of textBox1.Text, you should set what's called a breakpoint on the line that calls MessageBox.Show(textBox1.Text). To do this, click in the grey area of the source editor (it's on the far left) on the line containing MessageBox.Show(..). A red circle will appear and your code should be highlighted. When you run your application and click on your button, your application should pause and Visual Studio will highlight that line and from here you can hover over "textBox1.Text" in the MessageBox.Show() line and it should show you the current value.
If your application is as simple as a form, a textbox, and your button1_Clicked event handling code, this should work no problem. If it is not this simple, then you need to look for anything that sets the value of the textBox in your code and make sure it isn't passing any blank values by using breakpoints.
To solve this properly, though, we really need more information.

Thanks Eric and Crippledsmurf. As both of you said, its hard to help without the code.
The problem I found is that when calling the form, I send some objects by reference, so I can track them down and I found that when (don't ask me why it happens that way, I'm still working on it) the construtor is called he make an new component, so the component in the interface no longer represents the one pointed by the variable "textbox1" (Yes Crash893, I haven't mispelled the name).
I found that I was making some mess with the references, and probably that was causing the problem. I fixed the problem by changing the actions performed by references for delegates and events, but I couldn't track down the exactly source of the problem.
Thanks, again, everyone for the insights.