I've created a derived WinForm textbox control that knows how to provide a hint (those grayed out words that say things like "Password" or "Enter search here") as well as allowing for the beep on enter to be disabled.
I have two public properties BeepOnEnter, and HintText, a single method - ResetHint and then overrides for the Text property, the OnGotFocus event and the OnKeyPress event.
This code works fine until I have a need for a textbox on a tool strip also known as a ToolStripTextBox.
I'd like to use the same code for both the TextBox AND the ToolStripTextBox. Is there a way minimize/reduce redundancy? I definitely need code that has classes that are derived from TextBox and ToolStripTextBox so the ui designer allows me to drop these new controls on a form or tool strip but can't figure out how to do it in an OO way.
ToolStripTextBox is derived from ToolStripControlHost and TextBox is derived from TextBoxBase and as multiple inheritance is not allowed, you will be best off creating a 3rd utility class and putting all similar functions in it. You can then leverage an instance of this class in your derived controls to get the common functionality you want.
Related
If we want to add an Id to an AEM Core component such as image, there is this field:
.content.xml
<id
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
fieldDescription="HTML ID attribute to apply to the component."
fieldLabel="ID"
name="./id"/>
which gives this textfield in the dialog.
But what if we want to create the same textfield, but for CLASSES instead? The core components only seems to use the "./id" name, and nothing for classes.
As you can see I am an absolute beginner, so any pointer or help is much appreciated.
--- Edit (June 17, 2022):
Following Vlad's answer, I needed to narrow down where I am having issue:
I don't know how to "add a textfield for classes". For example, the id field has name="./id" in the xml, which can be accessed as "${image.id}" in the html. But the same doesn't exist for Classes.
How would the Textfield look like if I am adding it for Classes? Like this one obviously wouldn't work as "./class" is not connected to anywhere.
<class
jcr:primaryType="nt:unstructured"
sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
fieldDescription="HTML CLASS attribute to apply to the component."
fieldLabel="CLASS"
name="./class"/>
I guess that the name="./id" of the Textfield is tied to some Java logic so we can retrieve it via "${image.id}". I have looked at image's java code, but don't see how they tied together.
I would need to understand the Java code in order to override it. Or am I missing anything and there is an easier way? Again, absolute beginner here.
You can override the dialog and add a textfield for classes, then overlay the HTL script and inject the classes in the markup. However, I recommend you look first into the OOTB Style System. It allows you to define classes in the component’s policy and then use them in the editor (they will be added on the component wrapper element).
i m creating ocx for my own text box control
my question is "how i can set property for data format?"
Once you have a Public Property of type StdFormat.StdDataFormat (typically named DataFormat) you get the rest for free.
Actually making any use of that is a larger question. You may need an MSBind.BindingCollection depending on what is going on in your UserControl.
I am using EditorTemplates to style all my input fields. Works like a charm, however now I want two themes of EditorTemplates, one for normal forms, and then one for my wizard forms.
I am already using an overloaded Html.BeginWizardForm() around those Html.EditorFor - but how do I make the MVC logic react on being inside Html.BeginWizardForm() ?
EditorTemplates are designed to be somewhat global. You can override them, though, just like any other view, because they are just views. For example, assuming you have something like Views\Shared\EditorTemplates\String.cshtml, you can then create a another view at Views\Foo\EditorTemplates\String.cshtml, and for any action called from FooController, the latter editor template will be used instead of the one from Shared. You might be able to make this work in your scenario if the wizard form is used in a specific controller or area context.
Short of that, though, there's no way to have this occur automatically. Some manual options still exist, though.
You can decorate the properties of the view model used within the context of the wizard with UIHint attributes. For example, assuming the same shared editor template above, you could do something like:
[UIHint("WizardString")]
public string Foo { get; set; }
That would cause it to look for Views\Shared\EditorTemplates\WizardString.cshtml instead.
You can pass the editor template to use in the call to EditorFor:
#Html.EditorFor(m => m.Foo, "WizardString")
All that said, the biggest problem here is that you seem to be violating a pretty core principal of good web design. HTML is about structure, not presentation. CSS is for presentation. As a result, if you want something to look different in a certain context, the correct approach is to apply different CSS. If things are designed well, your HTML shouldn't really have to change.
It seems is as stated by Chris Pratt not possible to have multiple EditorTemplates.
I however found a workaround by extending the MvcForm and created a WizardForm which adds a value to the ViewContext (in my case "wizardContext" => true) and on disposing setting wizardContext => false.
This allows me in the EditorTemplates to add a check for if I am inside or outside the wizardContext, which will propagate through the nested EditorFor, and in this way allow me to have different themes, without having to be specific in EditorFor.
Some coding books mention that we should not prefix the type in the name, since current IDEs are able to make these visible and clear. I completely agree for primitive types but I'm inclined to still prefix my GUI components variable names.
What are the best practices when working with on GUI code regarding GUI component variable naming?
E.g. should I name my
Button btnSubmit
TextField tfName
Checkbox cbActive
or
Button submit
TextField name
Checkbox active
I find that generally, when naming GUI-components, prefixing the variable name with the type of GUI-component simplifies the process of writing code in that when I write code that references them, I don't have to remember the exact name of each component. E.g. often I know that I'm gonna get the text from a specific TextBox, but I don't remember the exact name of it. I start typing TextBox and up in IntelliSense a range of TextBoxes appear, from which I easily can identify the exact one I'm in need of.
Regarding if it's any best practices; It depends on
If your company has any standards, I'd assume they'd be the best practices in this case.
If it's a private project, go with what you feel is the best.
My 0.02$
So, I have a form in VB which is visible except when the program is started silently, in which case the form is still loaded but the interactions are done programmatically. However, in a tiny number of cases I want forms created within the invisible form to be visible. What is the best way to accomplish this, ideally without creating new forms. Some ideas I've come up with but really don't like:
Creating a new form, passing that form's hwnd so that it is hosting any applicable windows. Really easy to do, probably pretty flexible. Still ugly.
Calling the visible form manually, pulling out the values, passing the data filled in by the user to invisible form. This solution is probably the easiest, but it's also a hack. It's an awful solution if it was used for more than a tiny number of forms, but it will probably.
Creating a new class, refactoring the forms to be triggered by events.
Setting the main form to be visible, but perverting its load function so that it doesn't actually display anything.
Not using the invisible form at all, refactoring code to better separate functionality of form from usage. In truth, this is largely already true, but I don't see a way to do this completely without some repetition with the way the classes are used, since I'll end up needing to have to different classes which include the same function. Probably the idealistic solution, though.
What I actually ended up doing: Sticking a shell execute call in the affected place which starts a new instance of a copy of the program which was compiled with different flags. This isn't nearly as bad as it sounds. Part of the problem with using any other solution is that ANY time I want to slap a different UI on my code, I need to create a new controller class which handles the relevant events differently. THe majority of the program's interface is already kept separated from its implementation, but creating a new UI requires me to add extra event handlers and whatnot to it. Admittedly it would probably only need about 3 event handlers handle prompting the user for input when events are triggered.
Edit: To an extent, I have mistated my problem: The issue is that I want to recycle part of my existing UI, but not all of it. Thus, making the parts I don't want the user to see be invisible but making the menus that appear visible. Decoupling the individual UI components will probably end up adding additional complexity to the program.
the last option is preferable; after refactoring there should be no redundant code
fiddling with invisible forms is a pretty good indication of the need for refactoring!
I also recommend the last option. What I would do to safely implement with the least amount of changes is as follows.
Make a Backup or check everything into your source control and make a branch.
Make a new ActiveX DLL Project. I would name it some variant of UI_Controller
Note: A new project will force you to identify hidden dependencies within the EXE.
Have it reference everything the EXE is right now.
Have the EXE Project reference the UI_Controller.
Make a class for every major form in the application.
Copy the Minor Dialogs into the UI_Controller DLL.
For each form make a interface class in the UI_Controller DLL (The form will be
implementing this)
Example if you have six major forms you then have six form interfaces and six controller classes
Go through the form for each procedure and event COPY the procedure over to the UI Controller Class and make it public.
Make sure each controller class has an Init procedure.
However there is an exception and that is if the code only deals with other controls and the form. For example Resize event rearranging the code. The reason for this is that is logic specific to that style of form. A different form or UI using the controller class will have a different resize algorithm so it makes no sense to move that code over. You will have to use your best judgment.
Go back to the Controller classes. Many of the procedures will need to reference elements on a specific form or fire events on a form. Write a subroutine header or function in your form interface class to allow that event to occur or retrieve the needed information.
Note that if you find the same actions grouped together or the same series of information retrieved considered making just one subroutine instead of multiple.
Change any direct references to a form to a call on the interface.
Have your major forms implement each interface. Make a GlobalMultiUse Class in your UI Controller DLL that allows the EXE to register each form with it's controller. The register subroutines should only accept an object of the form interface. In your application initialize have pass each major form to the correct registration function before you do anything else.
Run your project and correct any errors. Note that the actual function of your software should remain the same as you should have only been copying and implementing.
When the software runs without errors. Check it into your source control or make a backup.
Start replace each procedure of ONE of your major forms with a call to corresponding method of your controller form. If any other form calls something on the form you are working on switch that call to the controller.
When you are done make sure the controller form initialization is called in your application initialization section. You make need to switch to using a Sub Main for this to work.
When this works properly work on another form. Keep doing this until all forms are converted.
Clean up anything that is not used.
Test and if it passes you are done.
What you have now is an application where you can rip off the current UI and replace with anything that implements the form interfaces. So you can have a invisible EXE, a unit test EXE, and your regular EXE.
You will have to decide what best for you based on the complexity of your application. You can have a partial conversion where you only give one or two forms a controller class.