I just discovered unit test projects in Visual Studio .NET and am using test methods to set up examples of global code I have developed.
Some global methods involve displaying reusable dialogs like a date-picker and input box. Trouble is, sometimes forms will display and sometimes they won't.
I thought it was related to modality, because I have a report preview form that can be shown modally or non-modally. When I show that non-modally, it does not display. When I show it modally, it does.
Trying my input box never works:
string input = "";
using (InputBox box = new InputBox(Title, Prompt, Default))
{
DialogResult result = box.ShowDialog();
input = box.txtInput.Text.Trim();
}
return input;
Execution stops at the "box.ShowDialog()" line, and at that point I can inspect box and see that its dimensions, location, and visibility are all properly configured -- yet I cannot see the form. I've got to cancel the test to stop everything.
I'd love to use a unit testing project to act as a playground and showcase of existing code, but it seems very limited if I can't display certain forms. I realize this is not really what unit testing is meant for, but I hoped I could build a fun little sandbox this way to help get my developers up to speed.
I finally had some consistent success (and lack thereof) based on a single form property: ShowInTaskbar.
When a form had that property set to true, such forms would NOT display from a unit test method. When that property is false, all forms display. So, here are the rules as far as I know them to make sure a form can display from a unit test:
The form should be created as a standard Windows Form item in the project.
The form should have its ShowInTaskbar property set to FALSE.
The form needs to be displayed modally (i.e. with ShowDialog()).
This has let me display and test all of my utility forms like date selectors and login screens.
I had the same issue. The dialog was blinking visible then disappearing. It was already TopMost, and I tried the other trick of setting it to visible then not visible before showdialog was called, but nothing worked.
Then I checked the other dialog that was working fine and it had ControlBox = true. I tried that, and it worked!
This is definitely applicable to the question.
Related
How can I prevent the showing of the Next or Done buttons of the Android VKB in a Codename One app?
Currently, for my app, they are a mess: the next button of the VKB doesn't focus the next field, but the previous. After tons of trials, I didn't find a way to make them working correctly (but there are fine on iOS and on the Simulator). I also tried to override the Layout.overridesTabIndices(com.codename1.ui.Container) and Layout.getChildrenInTraversalOrder(com.codename1.ui.Container) methods in the Form, but nothing changed on Android.
I supposed two possible causes: the use of a Form inside a Form or, more probably, the fact that I replace all the TextFields and Pickers in the same Form (and other components). Maybe the fact that the inner Form is deeply changed results in a confusion for the Android mapping of the "next" button.
That's why my request: because I didn't find a way to make the "next" button useful, I'm asking how I can avoid that it's been shown.
Thank you
Nesting forms would probably mess with the focus traversal/tab order.
Normally you should be able to override public TabIterator getTabIterator(Component start) to return a blank iterator. I'd suggest doing the same for both the parent and child form to disable the "next" feature.
In a test-class, is there any way to invoke Buttons inside the toolbar, without a name (""), which were added like this?
getToolbar().addMaterialCommandToRightBar("", FontImage.MATERIAL_PICTURE_AS_PDF, e -> createPDF());
Or can I somehow tell the test-class to show a specific form ?(which is happening when I click the button without a label).
The test recorder is not generating any code in that case. It seems that it is only working with buttons, which have a non-empty String as name, as they are simply invoked by
clickButtonByLabel("Label");
The test recorder was written before the Toolbar existed, we tried to update it for the Toolbar recently but this proved to be pretty difficult.
We have this issue that covers this bug. As a workaround you can post the command directly in the code of the test.
I'm having an issue in Coded UI where a HTMLButton is disabled until the user selects an item in a list box. At which point the button is enabled via javascript. The problem I'm having is that the recorder is not picking up the change. When I run the test I get a "ActionNotSupportedOnDisabledControlException". I've tried the WaitForControlEnabled, Find and WaitForCotrolReady methods but nothing seems to work. Is there a way I can make the button enabled in code?
First you need to check control is disabled or not visible.
I have faced same issue where control was hidden under another control, so it was not visible directly.
You can enable button by executing Javascript from your Coded UI test/script.
Javascript Code:
document.getElementById<ID>.disabled = false;
document.getElementsByClassName<>.style.visibility='visible';
Test/Script Code:
this.UIMap.Window.ExecuteScript(<above / your JavaScript>);
I've got a "Main Window" containing quite a few things, including, in the status bar (at the very bottom of the window), a "Support" button, which the user can use at any time to open a window containing our support phone number, along with a little chat functionality if the user prefers to chat with us.
The problem is that if the program is displaying a modal dialog, the "support" button is not clickable anymore.
Stopping using modal dialogs is not an option ; I use them because I sometimes want to force the user into performing a specific task before I can do something else in the software.
What's the best way to let the user contact the support without having to close the current modal dialog?
Modal dialogs should behave as modal dialogs, the user won't expect to be able to click a button in the main window even if it were possible.
Your best bet is to put a support button on the dialog too.
Using a shortcut key instead of a button may be an option. The functionality could be factorized into a base form class like this :
public class BaseForm : Form
{
protected override bool ProcessDialogKey(Keys keyData)
{
if (keyData == Keys.F1)
{
SupportForm f = new SupportForm ();
f.Show();
}
return base.ProcessDialogKey(keyData);
}
}
Not using modal dialogs is an option. You can disable other parts of your interface during the required interaction to get whatever it is that you need out of the user.
The solution is to avoid situations where the user 'must' do something. Modal dialogs often get in the way if, for example, the user wants to quit the application right at that moment, or see something in a backgrounded window, or refer to another part of your application. Instead of using them, design your interaction so that if there is a required action/piece of information, it's folded into the application logic.
Think about website design -- modal dialogs are very rarely found on the web, and for good reason -- they disrupt the user's workflow unnecessarily. And yet plenty of sites have 'required' information.
Don't use modal dialogs; they are a shortcut to avoid a better design.
This is a bit of a strange one, but I've been struggling for a few hours now and I can't understand what is happening.
I was wondering if anyone else has experienced this problem, and can perhaps explain it. I'm building a simple Winforms app and trying to use many of the built in controls.
Basically, I've got a form with a user control and some data capture fields. 3 of the fields are dropdown lists and on the user control I have a bindingSource control that binds directly to a Product class.
At run time I provide an instance of the Product class to the BindingSource and the class contains a property of ProductType. For simplicity I also added a List<ProductType> ProductTypes to the Product Class which loads itself when queried, which means I can just use the same bindingSource and choose the ProductTypes Data Member as the Datasource for the dropdownlist.
Upon running the form, the list binds perfectly and I can see all the product types listed, and I can select one and tab or click to the next field. But obviously the selected value won't bind because I've not chosen any bindings-SelectedValue for the dropdown, only a datasource. As soon as I make sure that the drop down modifies the instance of the Product by binding to the Bindings-SelectedValue, and then run the form, the list still gets populated perfectly and I can tab through the controls as long as I don't make a selection from the dropdown. If I make a selection from the dropdown then the dropdown holds focus. I cannot tab out for love or money and can't even click cancel button on the form, the close button top right is the only button I can click which works and I can't click any other field or dropdown. This affects all three dropdowns as soon as a selection is made.
Anyone have any ideas what I'm missing?
I have tried changing a few things and had some success by feeding the dropdown values a string[] instead of a member of an object. That seems to work, but defeats the object of using databinding doesn't it?
Any help appreciated!
Just guessing here, because I don't have time to set up a test and confirm right now, but are you doing any validating? I seem to remember that data-bound controls won't let you leave if the contents don't validate. Even if you aren't explicitly, try setting CausesValidation to False to see if there's any sort of validation going on behind the scenes, that might at least give you a hint.
Thanks for the input on this, helped me wrap my head around this.
In my case, it turns out that an exception was being thrown in one of the EventHadlers for my ComboBox.Validating event. It was hard to track down, because the IDE didn't show me that exception. I was able to modify the Exception behavior (in the debug menu) and have it show me any InvalidOperationException that was being thrown, and then I was able to track it down.
As Tom suggested, turning off CuasesValidation was the ticket to figuring it out.
For Infragisticst Dropdowns (may not be true for other winform dropdowns): If you have "LimitToList" set to true you can be stuck in a dropdown that you can't get out of without realizing it. Use the ItemNotInList even to trigger a warning message.