this might be a very very basic question, but what is the best way to name my forms?
I mean, can I use spaces or will that give me problems later on?
Example
Should I use "Logged on Popup" or "Logged_on_Popup"?
Thanks!
Don't use spaces. Or Underscores. Microsoft do have some naming conventions that they recommend. Whilst they don't specifically have any recommendations re: form naming, they may be quite a good read:
Do favor readability over brevity. The property name CanScrollHorizontally is better than ScrollableX (an obscure reference to the X-axis).
Do not use underscores, hyphens, or any other nonalphanumeric characters.
Also, bear in mind that the name used in your code isn't exposed to the end users - whereas the captions of your forms are - make sure that those captions are well chosen.
Since Forms are also classes, you should follow the Class Namings:
Use a noun or noun phrase to name a class.
Use Pascal case.
Use abbreviations sparingly.
Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.
Do not use the underscore character (_).
Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.
Where appropriate, use a compound word to name a derived class. The second part of the derived class's name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.
So Log On Popup is invalid and Log_On_Popup should be valid from a compiler perspective, but not from the class naming guidelines. I should opt for LogOnPopup. Where some people like to add a suffix to it LogOnPopupForm.
public partial class LoggedOnPopupForm
In component name you can use spaces but I don't recommend doing it
Simple,
You can use log_on_popup
If your doubt is how to name it then, When your Form designer is open, open the properties window (If properties window is not there, just right click on the form and select properties), In properties , You will find (Name) just type there log_on_popup :)
Related
Stuck at a trivial problem in Grails 3.1.5: Show the fields of a domain object, excluding one of them, including a transient property. Yes, this is my first Grails 3 project after many years with previous versions.
The generated show.gsp contains
<f:display bean="rfaPdffile"/>
This will include a field that may contain megabytes of XML. It should never be shown interactively. The display: false constraint is no longer in the docs, and seems to be silenty ignored.
Next I tried explicitly naming the fields:
<f:with bean="rfaPdffile">
<f:display property='fileName'/>
<f:display property='pageCount'/>
...
</f:with>
This version suprisingly displays the values without any markup whatsoever. Changing display to field,
<f:with bean="rfaPdffile">
<f:field property='fileName'/>
<f:field property='pageCount'/>
...
</f:with>
sort of works, but shows editable values. So does f:all.
In addition I tried adding other attributes to f:display: properties (like in f:table), except (like in f:all). I note in passing that those two attributes have different syntax for similar purposes.
In the Field plugin docs my use case is explicitly mentioned as a design goal. I must have missed something obvious.
My aim is to quickly throw together a prototype gui, postponing the details until later. Clues are greatly appreciated
If I understood you correctly, you want to have all bean properties included in the gsp but the one with the "megabytes of XML" should not be displayed to the user?
If that is the case you can do:
f:with bean="beanName"
f:field property="firstPropertyName"
f:field property="secondPropertyName"
And the one you don't wish to display:
g:hiddenField name="propertyName" value="${beanName.propertyName?}"
f:with
So list all the properties as f:field or f:display and put the one you don't wish to display in a g:hiddenField Grails tag
You can also try:
f:field property="propertyName"
widget-hidden="true"
but the Label is not hidden in this case.
Hope it helps
My own answer: "use the force, read the source". The f:display tag has two rather obvious bugs. I will submit a pull request as soon as I can.
Bugs aside, the documentation does not mention that the plugin may pick up the "scaffold" static property from the domain, if it has one. Its value should be a map. Its "exclude" key may define a list of property names (List of String) to be excluded. This probably works already for the "f:all" tag; bug correction is needed for the "f:display" tag.
My subjective impression is that the fields plugin is in a tight spot. It is intertwined with the Grails architecture, making it sensitive to changes in Grails internals. It is also required by the standard scaffolding plugin, making it very visible. Thus it needs constant attention from maintainers, a position not to be envied. Even now conventions for default constraints seem to have changed somewhere between Grails 3.0.9 and 3.1.7.
Performance of the fields plugin is sensitive to the total number of plugins in the app where it is used. It searches all plugins dynamically for templates.
For the wish list I would prefer stricter tag naming. The main tags should be verbs. There are two main actions, show and edit. For each action there are two main variants, single bean or multiple beans.
My answer is that at present (2 March 2017) there is no answer. I have searched the Net high and low. For the index (list) and create and edit views, the fields plugin works well enough. A certain field can be easily excluded from the create and edit views, relatively easily from the list view (by listing those that should show), and in no way I could find from the show view. This is such a common need that one would suspect it will be addressed soon. Also, easily showing derived values in the show view, like 'total' for an invoice. One can do that by adding an ordered list with a list item showing the value below the generated ordered list of values, but that is kind of a hack.
In some ways, the old way was easier. Yes, it generated long views, but they were generated and didn't have to be done by the programmer - just custom touches here and there.
I'm using EXTJS 4.1 and I'm naming my components as follows. If I create a store I end it with Store and I do the same for Controllers, Models, etc. So I may have UserStore.js. I then put it in a controller. Now EXTJS will create getter and setters for it but the way it does it, is they append the name "Store" to the end so I now have the following: getUserStoreStore(). Which I don't like.
But I want to append Store to my file names so I know what files I'm working in. So for example I may have a UserModel.js, UserStore.js, UserView.js, UserController.js. If I didn't I would have 4 files Called User.js and it would be a pain to always have to remember which file I'm working in.
So my question is there a config to change the way EXTJS names these getters and setters, or do I have to live with getUserStoreStore. It gets even uglier is I have sub dir under stores so for example if I have the following:
-store
-user
-UserStore.js
-UserPersmission.js
I define the store like this:
Ext.define('MyApp.store.user.UserStore'
I then get the following setter:
getUserUserStoreStore()
Yuck! Any idea or do I just live with this?
The short answer is No
You can only change it by overriding the method that creates the 'getter', cause there is no config. Other than, f.e. .Net ExtJS uses namespaces to identify the type (f.e. the controller namespace) and not a applied suffix. In addition; other suffixes are applied by the array into which the class has been placed (f.e. store, model, view).
I recommend you to just divide by namespaces.
I have this idea to try to use a custom IMPORT attribute to new up a class based on a condition. For example, if I have:
[Import("Position_32")] this should exist if I'm running a 32bit OS, and then:
[Import("Position_64")] if Im running a 64 bit OS. Is there any way to make the type name for the attribute dynamic based on a condition?
Conceptually it could look like this:
[Import(((IsWIN64()) ? "Position_64" : "Position_32"))] This doesn't work because the type name needs to be a constant.
I want to make the newing up of the proper position class as transparent as possible. I mean I did a factory based method using funcs to get my desired effect but I'd love to use MEF for this. Ideas?
THanks much,
David
You could use ExportMetadataAttribute like so:
[Import("Position")]
[ExportMetadata("Platform", "32bit")]
public YourType ...
Then, when you go to import, use:
[ImportMany]
public Lazy<YourType,IDictionary<string,object>>[] Positions { get; set; }
You can then check the Dictionary for the appropriate metadata, and use that specific platform, at runtime.
In addition, you can make a custom interface for strongly typed metadata (instead of strings). For details, see Exports and Metadata.
in a XAML file (a WPF UserControl), is there a way to reference an inner class "B" defined in another class "A" ?
public class A
{
public class B
{
}
}
Something like :
<local:A.B ... />
This syntax does not work because "B" is interpreted as a property named "B" in class "A".
I've tried more exotic syntaxes like "::" or "+" but none seems to work.
I'm currently using Silverlight 4 with VS2010.
Thanks in advance for your help.
This question is pretty old, and I don't know if it would have worked with the version of WPF back in 2010, but now you can make it work by using the "real" (internal) name of the nested type:
<local:A+B />
If you've ever looked a disassembled code, that's how nested types look like:
ParentTypeName+Nested
I was searching and searching, because if this is possible, I would like to know. Unfortunately, I found this on msdn:
Your custom class must not be a nested
class. Nested classes and the "dot"
in their general CLR usage syntax interfere with other WPF and/or XAML
features such as attached properties.
So, it appears you can't reference a nested class with the dot operator. As for alternative ways of getting to that inner class through XAML, I haven't had any luck in my searches yet. :o( But this is a rather interesting issue, so I will continue searching. Maybe I'll find some luck! :o)
. refers to a property; not sure why XAML couldn't also search for a nested class, but it doesn't.
A nested class can be represented when inside a string (e.g. a property value), using A+B instead of A.B:
<Label SomeProperty1="{x:Static local:A+B.SomeProperty2}" />
As an element name (as shown in question), + is not allowed, as the result would no longer be valid XML; + is not a valid name character:
XAML is XML.
XML Spec - NameChar.
So the element name cannot directly describe a nested class.
BUT see UPDATE below - an alternative syntax that solves this.
UPDATE
Per #Artfunkel's comment on one answer, this should be a solution [I have not tested]:
<x:Type TypeName="local:A+B"/>
From: https://learn.microsoft.com/en-us/dotnet/framework/xaml-services/x-type-markup-extension
TBD how to specify property name with that syntax. Use x:TypeArguments?
I have a set of names (first, last, salutation) and need a control to allow users to select a single name using WinForms. A ComboBox works fine if the there are ~20 names, but not so well when there are >100 names.
Can anyone recommend a name picker? Perhaps an address book control that I could customize? It's not too hard to write my own, but I have other wheels to invent.
I'm giving you an answer that seems more like a feature request... :-) It can be very easy to use if you implement a control which behaviour is similar to the auto-completion feature of Google: foreach char inserted by the user, a window appears with only the names that match with the string inserted.
I think that it isn't so hard to implement, but I'm sorry, I can't give you a recommendation, only an advice :-)
I agree with Maurizio. To add to his answer:
The most commonly used interface which does exactly this is in email clients, where they auto-complete names (and/or email addresses) as you type them. Thunderbird is a pretty good example. These usually either auto-complete if there is only one match, or show a drop-down list of possible autocompletions you can pick from. In addition, a button next to the field usually allows you to browse the address book as a list.
I'd also suggest filtering the autocompletions available in the most useful ways: e.g. As you type "wi", you could filter it down to names like "[WI]lson, John", "Amery, [WI]lliam", and "[I]ving, [W]alter", making it easy to find people by their initials as well as first and surnames.