Nate Lowrie wrote: > On Dec 4, 2007 10:41 AM, Paul McNett <[EMAIL PROTECTED]> wrote: >> Nate Lowrie wrote: >> >>> Note that OnHit is generally the controls main event. On a button >>> that means when it is pressed. On a list control it is when a list >>> item is selected. On a dTextBox it is when you enter text and hit the >>> enter key. It is a convenient thing to know. If you need specific >>> events, for instance on mouse over, then you can bind them with >>> bindEvent. However, only the Hit event may be bound from the control >>> instantiation. >> >> This isn't true; you can: >> >> txt = dabo.ui.dTextBox(frm, OnMouseLeftClick=myLeftClickFunc) >> >> or with any other Dabo event. > > I guess I learn something new every day...Sorry for the misinformation. > >> >>> On one last note, I think that you should make the dTextBox read only. >>> Coming from a correct code standpoint, if the users are entering the >>> dTextBox value through the dFileDialog, you should never want them to >>> type in the dTextBox directly. Makes error checking easier because >>> you only have to check for NULL and if the file is still there. I am >>> nit-picking, but it makes for good code. >> As a user I appreciate being able to enter text freely as well as being >> able to press a button to pick an item. For getting files and >> directories, it is *much faster* for me to type '~/my_file.txt' than it >> is to bring up a dialog and use the mouse to navigate to it. > > I would be willing to argue that it depends on the target audience of > the program. Suppose you are writing a business app for Joe's Apple > Orchard. All of the people who use the program aren't too computer > savvy. In that case, I think making the dTextBox read only is > warranted. In fact, I would be willing to bet with the browse button > there that Joe and his employees wouldn't think twice about using it > versus typing in what they consider a cryptic file path or doing > things like typing "myFile.txt" and forgetting the path. > > On the other hand, you have a point about freely entering text. If it > is an app geared toward programmers, admins, or more technical people, > then yes, the user should be able to enter text freely. I guess the > case in point is that you need identify what you target audience wants > and go from there.
And as you can't be sure about who is using it, you should simply assume that people who use it will use it as they want to use it. Why treating them to do it like you would use it? As more use cases a program is able to handle, as more people will be satisfied about it. Uwe _______________________________________________ Post Messages to: Dabo-users@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
