#VBTools – MhButton
7 messages in this thread
Mark, Recently I gave a friend a 'beta' copy of a program I've been working
on. While testing it for me, he found something strange that he tracked to
MhButton. He wasn't sure if I was doing something odd or if the control
was. Here is the scenario:
I have a control array (unrelated to the problem) of MhButton. I've
defined this button as a 'state' button. If you 'click' the button and
continue to hold the mouse down, then move the mouse off the button and
release it, the button's appearance changes, the 'state' or value changes,
but no click event is triggered to tell me. Does this make sense? Here's
how I tested it. Add an MhButton control to an empty form. Change the
State property to true. In the MhButton1_Click sub, add the following
line:
debug.print MhButton1.Value Now run the program. Click the
mouse on the button a few times to observe the 'value' printing. Now click
the mouse on the button and continue to hold the mouse button down. Now
move the pointer off the button and release the mouse. The appearance of
the button will change, but no click event ocurred (it shouldn't) and the
state changes (it should not). Somehow this seems inconsistent to me.
Please let me know if this is really an error and if it's fixed. BTW, I've
signed up as a 'beta' tester for VBTools 2.0 (why is this so
controversial????????????). When will I know that I'm official?
Bruce
There is 1 Reply.
Bruce,
I was able to duplicate what you described. As an aside, the VB standard
button does the same thing.
However, we agree that it's not *appropriate* when you have
StateButton=True. We'll be working on this today and tomorrow and we hope
to have a solution very shortly.
Thanks for finding it!
Mark
There is 1 Reply.
Mark,
I appreciate your attention on this matter.
In another quick matter; I've been telling everyone about VB and
VBTools/VBMuscle. Everyone is excited about Visual Basic, but some are
wary of third-party routines like yours. I embrace these routines
enthusiastically and don't hesitate using them. But some of my colleagues
express negative feelings towards including multiple DLL's with their
application. I've responded that they should look at WinWord or Excel and
they'd find many DLL's there also, but this did not reassure them. Do you
have any opinions on this? Obviously MS has intended this to be the norm,
since they created CDK as a method for enhancing/extending VB.
Just curious,
Bruce
PS – I received my notification about the VBTools 2.0 program today and
will soon begin using the latest and greatest!
Thanks!
There are 2 Replies.
Bruce,
>Some of my colleagues express negative feelings towards including multiple
>DLL's with their application.
You are correct – MS has "intended this to be the norm". Like any other
situation where people have "objections", this is a case of identifying the
objections and educating the person as to the whys and wherefores.
The real advantage of DLL's doesn't become apparent until you have *two*
apps that use the DLL. In that case, it's very obvious because you can
explain that the two apps "share" the DLL code.
So, the way I would approach it would be to say "we're doing it this way to
provide for upward compatibility at a later date. Future programs we ship
will use the same DLL and will result in faster installation/setup and
ultimately require less disk space."
Mark
There is 1 Reply.
Mark,
Thanks. I will definitely use that argument. This attitude comes somewhat
as a surprise, since mainframes and minis have long used some form of
"Subroutine Library". On the Wang VS, they are called Shared Subroutine
Libraries and are used for the same arguments you iterate. I believe most
individuals "fear" is really of third-party routines from smaller
businesses (like MicroHelp). The industry as a whole seems to have shifted
from dealing with the small business (sometimes only 1 or 2 people) and go
exclusively with "the big boys". How soon they forget that MS and Borland
started in exactly the same way. Well, not exactly. Not all of us came
from a rich enough background to buy a quick and extremely dirty OS and
….. Excuse the digression!!!!!!!!
I appreciate your arguments. Long live the entrepeneur!
Bruce
There is 1 Reply.
Bruce,
I understand the concern about "small businesses". In answer to that type
of objection, you might want to mention that there are NO big businesses
providing such subroutines for BASIC and VB — the market is too small for
the big boys. OTOH, it's just right for a small business.
If it makes any difference, we've been doing this since 1985 and each year
we've released more products than the last, increased sales and added to
our staff.
Mark
Bruce,
Message #2497 was meant for you – we've modified the MhButton control to
work as we think it should!
Mark