Develop Reference

selenium c# - "lazy" driver.FindElements(By..)

In my effort of trying to find a neat way to validate which buttons are visible to the user based on his Role and Permissions i have encountered a problem. I am using the Page Object Model design pattern with selenium to test a website. A few pages have a different set of buttons which should either be visible or not to the user according to his role.
I keep a Dictionary<Permission,IWebElement> and initialize it in the constructor of the page (class representing a certain page in the site).
All web elements are defined as follows:
private IWebElement btn_openShop => driver.ById("open_shop");
(ById is equivalent to FindsElement(By.Id("open_shop"))
The problem is that if the button shouldn't exist an exception is thrown when adding it to the Dictionary.
Note: moving the initialization of the Dictionary wont help since i test both cases (one in which the user should see the button and one in which he shouldn't).

I changed the Dictionary to be of type <Permission,Lazy<IWebElement>>
and added items to it as follows:
dictionary.Add(somePermission,new Lazy<IWebElement>(()=>the button))
Edit: this technique works but it seems that when debugging in visual studio the code crashes.
Any thoughts? (no exceptions are thrown during test execution).

Supporting custom user vocabulary/labels in WPF application

In the application I'm developing, the same software package serves many industries, and those industries have different vocabulary for what is essentially the same thing. The application is a C# server, to which a WPF desktop app makes socket-based XML requests.
For example, some customers may call something an "Item", some call it a "Part", or some call it a "SKU".
The goal is for the application to be able to relabel itself based on a "Vocabulary" setting that we create for the user. Typically, a given customer's vocabulary will only differ by perhaps 5-25 words/phrases out of the entire application. These custom vocabularies are specific to/created by the customer, and wouldn't be kept with the main application distribution.
My initial thought was to do this with custom CultureInfo, (e.g. "en-AC" for "Acme" company), supply just values that differ from the base en-US in that resource file.
The en-AC.resx resource could be kept on the server, loaded by the server, and also transmitted for loading into the WPF client app.
Problem with that thus far seems to be that the ResourceManager does not correctly pick strings for custom cultures, a'la this thread, and I've not been able to solve that yet. As well, as the app is ClickOnce deployed, we may not have permission to register a new culture.
My next thought, since the number of phrases to modify is so small, was to replace the resource value at runtime, but that seems to be a bit of a no-no as well, searching around.
So, thought I would ask the community for their suggestions on how to handle this.
Open to suggestions and ideas...

Because it's only about a few words I think I'd do it via a naming convention. Suppose you defined the string key "MyCompany". You usually access this way:
string myString1 = Properties.Resource.MyCompany;
But it is also ok to Access it that way:
string myString2 = Properties.Resource.ResourceManager.GetString ("MyCompany")
It's exactly the same (but dealing with strings as identifiers - which is somewhat error prone). What you now can do is to check for a special name first that you syntesize like "MyCompany_AC". The drawback is you need your own wrapper for each string:
string MyCompany
{
get
{
string myString = Properties.Resource.ResourceManager.GetString ("MyCompany_" + theCompanyPostfix);
if (myString == null)
{
myString = Properties.Resource.ResourceManager.GetString ("MyCompany");
}
return myString;
}
}

C# and Windows Forms control naming guidelines

Does anyone have any guidelines/best practices for naming conventions for Forms and controls (e.g., events, buttons)?

I usually use Systems Hungarian notation
Example:
btnSubmit: is button
lblAccountNum : variable is a label

In WinForms I usually use suffixes, so for example:
submitButton
accountNumberLabel
etc.
But a lot of companies still use a prefix, like anthares said.

I don't believe any special rules are needed for forms development; the Microsoft .NET naming guidelines cover it.
I name forms like any other class in the application: MainForm, SaveDialog, etc.
I name controls like any other field within a class: okButton, nameTextBox, etc.

I usually prefix the full class name e.g. textBoxName. I find it easier to read than three letter prefixes and it's consistent with the names that are generated by the IDE. I only name controls that are referred to by code. Controls that are databound usually don't need a name.

The following example is most of the .net programmer is used
Control: Label
Prefix : lbl
Example: lblFirstName

The reason that the prefixes are not the full class names in most of the companies but some abbreviations of the class name are as follows:
Most of the naming conventions are approved before Visual Studio 2010.
All Visual Studio versions before 2010 have their inteli sense filter with something like "starts with" instead of contains.
That's why a lot of people / architects / leaders decided it will be a better idea to type "txt" and inteli sense will filter all textboxes for you, so then you just type "E" for example and you get txtEmail. If you have the full class name, you will need to type "textBoxE" to get the same result in inteli sense. This adds a lot of overheat when you have complex UI.
Now with Visual Studio 2010 you get a better inteli sense so you can just type "em" and you can easilly see the "textBoxEmail" in the list (along with Email and some other things that contain "em"). Still I seem to prefer to have 2-3 or up ot 4 letters abbreviation that will allow me to filter in inteli sense by control type (specially for UI) than having to type textBox. The reason I prefer it is that even if you are puzzled for a while with some control type (e.g. "rg" for RadGrid) you will need 5 minutes 3-4 times to remember it and start typing without thinking about it. While if you have radGrid everywhere you will need to hit 7 strokes to get to the meaningful one that will filter for you (e.g. "radGridC" in "radGridCustomers").
I do agree that only naming controls that are referenced in the code is usually enough.

(.net) Kind of design question

My typical application has a couple of textboxes, checkbuttons, radiobuttons, and so. I always want to load the settings the user used the last time when the program starts, and also want to save the settings as the users clicks "Save settings" or closes the application. When the user attempts to save the settings, I'll have to check each of the controls for input errors (sometimes they have to have a max length, other times only caps, other times other things, there isn't a rule for them all, everytime it'll be different), and only if everything's OK i'll let him save the options. If there is something wrong, no option is saved and my errorcontrol provider will pop up a description of the input type info that should be put in that control.
I've been designing this from scratch for all my projects, but it's being a pain to do it. So I'd thought maybe now was the time to do some library to help me. I thought initially that maybe it'd be a good idea to have all the controls on my form that are going to be part of this save/load process to have an attribute associated with them, something like this
public delegate bool InputIsOkHandler();
public class OptionsAttribute : Attribute {
public Control controlRef;
public InputIsOkHandler IsInputOk;
public string errorMessageToShowOnErrorProvider;
public OptionsAttribute(Control controlRef, InputIsOkHandler inputHandler, string errMessage) {
...
}
}
The main problem here is that when I declare the attribute on a given var:
[Options(...)]
TextBox textBox1 = new TextBox();
I'll get
Error 1 An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type.
So I guess this approach isn't the best one. What would you guys do in this situation? Would you use attributes? Would you use other mechanisms?
Thanks

Do you know that .NET already includes such a system since 2.0? See MSDN, CodeProject and this white paper from WestWind.

The Personalization and User Profiles supported in ASP.NET 2.0 can be a nice way to achieve your goal.
You can check this MSDN article for a overview Personalization in ASP.NET 2.0

Properties embedded within another object

I am trying to use a business object that I am passing to the report.rdlc. The properties in my object are not directly exposed. The properties I require are embedded within another object inside the top level object. As this is a WCF project I can't control what goes on at the server end. I am just able to request these objects or Insert/Update/Delete their info from the database. It is done in this way as the back end can use multiple flavors of database.
Here is what I can see after adding my business object as a DataSource:
-BusinessObject
-CustomerInfo
-ClientName
-ColumnName
-DisplayName
-FieldName
-IsNull
-KeyColumn
-SenondKeyColumn
-StringValue
-ClientID
-ColumnName
-DisplayName
-FieldName
-IntValue
-IsNull
-KeyColumn
-SenondKeyColumn
+ClientAddress
+Instrument
+Telephone
etc etc
I need to be able to display, for example, the ClientName.StringValue field.
If I drag the field I want onto the report I get:
=First(Fields!StringValue.Value)
This doesn't display anything when the report is run, I assume because it can't qualify what StringValue it is talking about and there could be many.
If I try dragging the ClientName object I get:
=First(Fields!ContactName.Value)
However this gives:
#ERROR
When the report is run.
I would have thought you could use:
=First(Fields!ClientName.StringValue.Value)
but this won't even let me build.

The problem was that the info wasn't at the root level. I worked it out though.
=First(Fields!ClientName.Value.StringValue, "BusinessObject_CustomerInfo")
I've got a pretty good grip of the ReportViewer component now cheers.

If you set the data source to the CustomerInfo instance (or list) returned from the service it should work. The ReportViewer control can be a little complicated when you start dealing with object hierarchies, but you don't have to do anything crazy or special if all the information is at the root level.