Controls Wish List

[Greg Empey]

Lately I have been developing Client/Server 'N' tier applications and my
number one beef with VB is their controls. They are an absolute joke. The
only control that semi works is the text box, but even it has some
shortcomings. Here is a list of the controls that need to be made
professional (in no particular order):

1) tab control (one that doesn't shove the controls to -76000 or whereever,
and provides more functionality)
2) grid control (one that gives you absolutely complete control over it, and
includes combo box functionality)
3) list box control( one that can display and work with more than one
column)
4) combo boxes (one that can display more than one column in the drop down)
5) text boxes (one that can accept nulls and will automatically highlight
the text)
6) radio buttons (that are data bindable)
7) toolbar ( one that allows you to but pictures in the button menus)
8) status bar (one that provides better control over it)
9) A reporting tool (one that can actually be termed a reporting tool and
not a one document displaying tool)

When you buy a professional (or enterprise) edition of a software product
you expect it to have controls that at least allow you to develop a standard
applications. Everybody seems to think it is okay to purchase third party
controls, well, I think that is ridiculous. We have ended up using Sheridan
controls and they don't bind worth a **** and are so buggy that we spend
more time creating work arounds than writing business logic.

Now I don't want to get into a Powerbuilder/VB debate, but at least
Powerbuilder ships with all of the controls you need that they work the way
a developer would expect them to work.

My 2 cents worth.

Greg Empey
CGI Consultant
greg.empey@cgi.ca

[Mark Hurd]

"Greg Empey" <john.henry@stopspam.com> wrote in message
news:38cd2004@news.devx.com...
> Lately I have been developing Client/Server 'N' tier applications and my
> number one beef with VB is their controls. They are an absolute joke.
The
> only control that semi works is the text box, but even it has some
> shortcomings. Here is a list of the controls that need to be made
> professional (in no particular order):
>

<some points snipped>

> 1) tab control (one that doesn't shove the controls to -76000 or
whereever,
> and provides more functionality)

To become professional, it needs to stop changing the order of its data as
stored in the *.frm file, so that source code control tools don't see scads
of changes that aren't really important.

> 5) text boxes (one that can accept nulls and will automatically highlight
> the text)

Assuming you mean vbNullChar, that is a C or Win32 bug/feature, and
highlighting text has to be done by the programmer, using only two lines of
code, because everyone has a different idea as to when it should happen.

> 6) radio buttons (that are data bindable)

Ahrrrgg! Use the objects, you'll have to when you code gets to complex
anyway.

<snip>
>
> My 2 cents worth.
>
> Greg Empey
> CGI Consultant
> greg.empey@cgi.ca
>


--
Mark Hurd, B.Sc.(Ma.)(Hons.)
Director of Software Engineering
Netline Technologies International Ltd

[Brian Higgins]

"Mark Hurd" <markhurd@ozemail.com.au> wrote:
>"Greg Empey" <john.henry@stopspam.com> wrote in message
>news:38cd2004@news.devx.com...
>> Lately I have been developing Client/Server 'N' tier applications and
my
>> number one beef with VB is their controls. They are an absolute joke.
>The
>> only control that semi works is the text box, but even it has some
>> shortcomings. Here is a list of the controls that need to be made
>> professional (in no particular order):
>>
>
><some points snipped>
>
>> 1) tab control (one that doesn't shove the controls to -76000 or
>whereever,
>> and provides more functionality)
>
>To become professional, it needs to stop changing the order of its data
as
>stored in the *.frm file, so that source code control tools don't see scads
>of changes that aren't really important.
>
>> 5) text boxes (one that can accept nulls and will automatically highlight
>> the text)
>
>Assuming you mean vbNullChar, that is a C or Win32 bug/feature, and
>highlighting text has to be done by the programmer, using only two lines
of
>code, because everyone has a different idea as to when it should happen.
>
>> 6) radio buttons (that are data bindable)
>
>Ahrrrgg! Use the objects, you'll have to when you code gets to complex
>anyway.
>
><snip>
>>
>> My 2 cents worth.
>>
>> Greg Empey
>> CGI Consultant
>> greg.empey@cgi.ca
>>
>
>
>--
>Mark Hurd, B.Sc.(Ma.)(Hons.)
>Director of Software Engineering
>Netline Technologies International Ltd
>
>In reference to the above statement that it only takes 2 lines to highlight
text in a text box -- I could use this feature. Please give an example.
Thanks

[Colin McGuigan]

Brian Higgins wrote in message <38df9150$1@news.devx.com>...
>In reference to the above statement that it only takes 2 lines to highlight
>text in a text box -- I could use this feature. Please give an example.
> Thanks
>

Private Sub txtTest_GotFocus()
txtTest.SelStart = 0
txtTest.SelLength = Len(txtTest.Text)
End Sub

Aaand, optionally:

Private Sub txtTest_LostFocus()
txtTest.SelLength = 0
End Sub

As far as the textbox goes, I don't think it'd be too hard to simply add on
a property (HighlightOnFocus?) that would do this programmatically...but,
then again, if we can inherit and extend controls, it won't be a problem
anyways. =)

--
Colin McGuigan

[Jim Pragit]

C++Builder and Delphi call this property AutoSelect. It's turned on by default.
Most professional applications only highlight text if the user tabs to the
control. If the user uses the mouse, the keyboard cursor goes to the position
where the mouse is. The code you posted doesn't make this distinction.
A built-in property (theoretically) should solve this problem.

- Jim

"Colin McGuigan" <colin@chicor.com> wrote:
>Brian Higgins wrote in message <38df9150$1@news.devx.com>...
>>In reference to the above statement that it only takes 2 lines to highlight
>>text in a text box -- I could use this feature. Please give an example.
>> Thanks
>>
>
>Private Sub txtTest_GotFocus()
> txtTest.SelStart = 0
> txtTest.SelLength = Len(txtTest.Text)
>End Sub
>
>Aaand, optionally:
>
>Private Sub txtTest_LostFocus()
> txtTest.SelLength = 0
>End Sub
>
>As far as the textbox goes, I don't think it'd be too hard to simply add
on
>a property (HighlightOnFocus?) that would do this programmatically...

[Jim Pragit]

"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>
>The code you posted doesn't make this distinction.

I want to clarify that I'm not trying to be critical. In fact, I use the
same code because the alternatives I've seen are worse. I'm just pointing
out that another advantage of an AutoSelect property would be that this problem
could be eliminated.

- Jim

[Matthew Cromer]

"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>
>"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>>
>>The code you posted doesn't make this distinction.
>
>I want to clarify that I'm not trying to be critical. In fact, I use the
>same code because the alternatives I've seen are worse. I'm just pointing
>out that another advantage of an AutoSelect property would be that this
problem
>could be eliminated.
>
>- Jim

If you download my SDAEnhancedTextbox source, you will see how I work around
this problem.

I place a test to see if the mousebutton is depressed when the control gets
focus, and if it is, I don't autoselect the control

Matthew Cromer
http://www.sdaconsulting.com/

[Colin McGuigan]

Jim Pragit wrote in message <38dfa55d@news.devx.com>...
>
>"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>>
>>The code you posted doesn't make this distinction.
>
>I want to clarify that I'm not trying to be critical. In fact, I use the
>same code because the alternatives I've seen are worse. I'm just pointing
>out that another advantage of an AutoSelect property would be that this
problem
>could be eliminated.
>
>- Jim

Well, yeah; I agree with you (AFAIK, the only advantage to auto-highlighting
text is for someone doing heads-down data entry via the tab key). He just
asked how to do it via two lines of code. =) The best solution, I think,
would be to extend the textbox yourself via inheritance; that way, if the
ability to seperate getting the focus from the mouse and keyboard became
essential, you could go back and do it yourself, rather than having to
rewrite a lot of code (which might happen even if Microsoft exposed it as a
property. Lord knows there've been enough problems with those, especially
re: the common controls...)

--
Colin McGuigan

[Jim Pragit]

Matthew,
Very nicely done! I've seen two other methods to accomplish this very
same task but one suffered from an annoying flaw and the other was just too
ugly to actually use (a module-level variable for each textbox, if memory
serves me correctly). I'll have to integrate this into my code library so
I can add this functionality to all my apps. I guess I'd still rather have
an AutoSelect property but until then, this is the next best thing. Thanks!

- Jim

"Matthew Cromer" <matthew@sdaconsulting.com> wrote:
>
>"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>>
>>"Jim Pragit" <James.Pragit@BakerNet.com> wrote:
>>>
>>>The code you posted doesn't make this distinction.
>>
>>I want to clarify that I'm not trying to be critical. In fact, I use the
>>same code because the alternatives I've seen are worse. I'm just pointing
>>out that another advantage of an AutoSelect property would be that this
>problem
>>could be eliminated.
>>
>>- Jim
>
>If you download my SDAEnhancedTextbox source, you will see how I work around
>this problem.
>
>I place a test to see if the mousebutton is depressed when the control gets
>focus, and if it is, I don't autoselect the control
>
>Matthew Cromer
>http://www.sdaconsulting.com/
>