Is it bad practice to handle the showing of the open file dialog, and other dialogs, from within a custom textbox control? - mvvm

I am making a custom textbox control and am thinking about adding keybindings in the constructor that execute commands to open and save files. I am also thinking about handling the find and replace dialog from within my textbox control.
Is there a reason I shouldn't do this?
--Edit--
I am planning on only using this control in my current application. One of the reasons I am thinking of doing this is to avoid binding to the textbox's Text property, since this binding seems like it would be just as inefficient as updating a string on the textbox's textchanged event.

Well, flexibility comes to mind. Consider the following scenarios, which would be impossible (or at least difficult) in your control:
You want to handle multiple or different methods of opening a file, but it depends on your application.
You want to use your textbox but limit the functionality -- e.g., Find/Replace is not allowed.
You want to change the behavior of any of that in one application but not the other. For example, in app A you want to tack on an extra slash to the end of the text, but in app B you want to add a custom folder name.
In general, I would consider something more generic. Something like a textbox has a specific purpose; enhancing that purpose is fine, but you're going beyond that. You're taking logic that rightly belongs to the app and putting it on a specific control. That limits what you can do with the control across multiple apps.
Of course, if you're writing a control specifically for one and only one app, you don't need to worry about these things. But I would still consider it a bad practice, myself.

Related

Access 2010 Form: Including example input for fields?

I have an input form in which users submit multiple types of information to the database.
Is there any way I could provide an example input of what should go in each field, upon the form loading?
Some fields I'd expect a small paragraph of text, others are dropdowns. The dropdown fields I wouldn't need to put an example of course, just the string text fields. If I try and include an example in the Default value for example, it would save the default value, which I wouldn't want.
Any help is greatly appreciated - It's worth noting I'm quite new to Access & coding in general.
I agree you probably don't want to use default values, or actually enter dummy data into the actual controls for the reason you mention: saving dummy values to the table.
A few possibilities:
Use a custom tooltip. You can do this by editing a control's "controltip text" property. Keep in mind that tooltips are only visible to the user when they hover the cursor over the specific control.
Add a label below the input control that describes the information that should be put in the control. This would always be visible, but can quickly cause your form to be cluttered and difficult to read.
I should say though, that you want to attempt to make your forms as intuitive as possible. For example, if you expect a paragraph of text, make the textbox much larger than a control only expecting a 6 character string. The more you are concerned with UX (user experience), the greater the chance that users will pick up on expectations using subtle design hints. I highly recommend researching the topic if you are concerned that your users will be unable to decipher the purpose of your form/controls. Be sure to check out the UX page on SE.
Furthermore, you can utilize a control's "AfterUpdate" event to validate the input placed in the control as soon as the user moves away from it. For example, you could test if the input IsNumeric() to validate that numbers were entered instead of text. If text is found, you can use a message box to alert the user, and move the cursor back to the control that is invalid.
Of course, that's the customized approach to just using the control's validation rules. The only issue I have had with the standard validation rules is user exhaustion. It can be irritating for a user to deal with validation messages when they are already aware that a typo was made. With an unbound entry form that requires a save button, I usually batch all control validation into the save procedure. This allows the user free reign to skip controls in the tab order without being blocked by constant validation exceptions.

Localization in Visual Basic 6

Is there a best way to localize the language settings? Say the situation is that you have already a working application in, say, French, and wanted to completely localize it in English.
So is there any way to easily localize the application while minimizing the impact on the application's code, I mean there mustn't be any major changes to the code itself but adding some would suffice. I've heard of using resource files in VB6 but it seems to have an issue with its fonts specially in Japanese characters, it throws out a garbage chars specially on labels. Now, what's the best way to change the charset of a application without applying too much changes in the applications code.
This application has a legacy code to I have to deal with it.
I use resource files, and replaced (almost) every string in the codebase and UI with an ID.
Whenever I display a string, I then call a single function that takes a string like {#1234} and loads string ID 1234 (using LoadString() and returns it.
For the UI, I enumerate every control on the form and pass the visible strings to the same function.
This meant a single call to Localise Me in the Load event of each form and a TranslateString("{#1234}", "name", Name) whenever I set/display something dynamically.
For the fonts, see this example from the Visual Basic Programmer's Guide. I call this on every control as part of the Localise method.
Don't forget that different fonts and languages take differing amounts of vertical space for the same text. The form layout also needs to be adjusted to take this into account, or reflow dynamically (align controls to longest label, shift down to allow for longer full width text, etc.)
Regarding the "while minimizing the impact on the application's code" part of the question, I would suggest encapsulating the resource-lookup-related features into a class of its own, exposing methods to fetch a string (by passing a culture specifier argument).
Then the bulk of the work is to convert your code from perhaps hard-coded strings to method calls to retrieve the appropriate strings. Implementing a variant of this answer: Implementing String.Format() in VB6, could greatly simplify your life if you also encapsulate the notion of 'culture' and introduce some cultureInfo argument to this StringFormat method's signature (perhaps call it StringFormatLocal).
The point being, if the current app isn't localized, it's probably not concerned about localization; localizing it means introducing a new concern so in order to affect legacy code as little as possible, you'll need to seek & destroy "magic strings" and "magic formats" all over the code base (and if your UI has hard-coded design-time captions and images, remove those as well), replacing them with calls to your localization API - keeping the localization concern separated.
I'd like to see another answer here with more details about storing, loading and especially using non-ANSI string resources...

how can a word add in keep its documents under custody?

I am developing a Word add in that is intended to create randomizable test bank documents. I would like the add in to prevent user entry outside content fields where there will be texts of questions and choices. I tried protection applied outside the content controls, but that requires the add in to frequently unprotect and reprotect the documents with the risk of any intervening error leaving the document unprotected.
If anyone can suggest an alternative method, I will appreciate it.
Hurol Aslan
After trying the protect/unprotected approach, I found that it does not let me nest a locked content control (for providing code-defined content) within a content control open to editing. However, I can set LockContents properties of nested content controls independently. That is the approach I will go with.

Best approach to test GWT localization?

I have a set of GWT UIs, some created directly in Java and others created using UI Binder ui.xml files.
I localized them following the official GWT guidelines (e.g. creating interface extending Messages interface).
I now wonder if there is an easy way to write a unit test to validate that message keys get replaced by the corresponding values from property files?
I guess I could do that using GWTTestCase, but actually I don't need a browser to render the page. Instead, it would be enough to get the raw string output and check with some regex that the messages are present.
Is that possible? Or is it better to test such things in running application like using Selenium?
Just a note. Besides the important things you are trying to validate, one of the critical points in my project during messages localization tests is to see: if the translated text fits the allocated space. If it's a box of fixed size, overlapping texts don't look nice. And this cannot be checked with unit tests. That's why the manual review is in to-do list when new locale is added or certain labels/messages are changed.
I'd recommend Selenium. Checking that the messages are present could be tricky, because in that case you should know the place where the label is located, in which tags. In my opinion, using GWTTestCase makes sense when it comes to testing controllers' behavior. Simple search by value guarantees only presence but not correct placement.
I think, it also makes sense to use those translation properties in the tests, so the strings are not duplicates in the tests.

Developing a GUI Builder Application

I am looking for a nice framework for developing a GUI builder Application. We have an application where 100Os of custom data entry forms and their print formats are required and each client will need some modifications on these. We have a developed a product using java based open source templatnig frameworks so that the layout and field definition are stored in database and rendered dynamically to the user. We also have an appication to design these forms but cannot do visual design.
Now I am trying to make a Visual Form Designer application for generating these forms. Can any one suggest some open source frameworks than can be used? Can I use Eclipse Visual Editor? Or is it better to develop some kind of parser for HTML using AntLR and then parse the HTML output from already existing GUI builders like Dreamweaver to get the desired output?
Thanks and Regards,
-- Kannan
Oooh, great question!
I wouldn't know any readily availble framework that you can use. Depending on your needs however, I think rolling your own shouldn't be too hard.
First of all, you probably wouldn't want to give the users too much freedom. Freedom only gives them the opportunity to mess things up and make the resultant forms hard to use. I think from your description that the fields are pre-defined, so that the user only needs to customize which fields appear on a given form, and in what order. Order can be a simple thing like top-to-bottom. Some semi-intelligent automatic layouting could be used to conserve screen space. Adding a feature to group fields together would probably also be useful, and grouping would lead to some kind of standard "group" widget.
Accepting simplified functionality like this, you don't really need the flexibility of a full gui editor. A couple of listviews, maybe a property sheet and a preview window will be enough to give your users the functionality they need.
Of course, this only holds for screen forms. Print forms may be trickier to layout, as people may want to cram as many fields as possible into very little space so the entire form can fit on a single page or something. I really don't have any suggestions for you there, but maybe a similar "simplified" approach with some intelligent auto-layouting could work.
Overall, my advice would be: Keep It Simple! (S... ;)