I have a BUNCH of  buttons that all do pretty much the
same thing, similar to:

'--------------------------------------------------------
Private Sub btn_Scale_0132_Click()
    Call mod_Scales.setImperialScale(SCALE_0132PLANS)
End Sub

Private Sub btn_Scale_0116_Click()
    Call mod_Scales.setImperialScale(SCALE_0116PLANS)
End Sub

Private Sub btn_scale_0332_Click()
    Call mod_Scales.setImperialScale(SCALE_0332PLANS)
End Sub
'--------------------------------------------------------

The values they're passing are constants.  Is there a better
way to do this that would reduce what *appears* to be
lots of redundant-type code?

TIA for your help and suggestions.

Show quote Hide quote I'd probably look into making the buttons into a control array and using the
Index parameter to identify the value to pass or using the TAG property of
each command button to hold the value.

Private Sub cmdScale_Click(Index As Integer)
Call moScales.setImperialScale(CLng(cmdScale(Index).Tag))
End Sub

(sorry, just can't bring myself to use _ in a name or 'btn' for a command
button... BTW, what does 'mod' stand for in 'mod_Scales'?  Is that a BAS
code module reference?)

Bob Butler wrote:
Show quoteHide quoteBob -

Thanks for your reply.  I'll experiment with this.

Yes, "mod" denotes (connotes?  Hehe) a code
module in my naming scheme, and probably
advertises my inexperience.  Would you recommend
using some other convention?
----------------------------------------
MicroStation V8.5.2.38
Windows XP Pro SP2
IE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158

Show quote Hide quote I just don't normally prefix calls to module-based procedures.  It's not a
bad idea, just not commonly done in my experience.  I had read it at first
as 'mo_Scales' and assumed it was a module-level class reference which is
why I altered it to 'moScales' and then saw the 'd' in there...  One thing
for sure I'd never be able to use your conventions since I find underscores
to be butt-ugly and hard to read in many fonts.  I use them only *very*
rarely.

Show quote Hide quote fwiw, we use a "slightly modified" version of this document religiously.

Visual Basic Coding Conventions
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconcodingconventionsoverview.asp

Thanks for this link.



Ken Halter wrote:
Show quoteHide quote

HA! I can't bring myself to use "cmd" for a button. "Command button," feh.
It's just another piece of dumbed-down terminology for us stupid VB people.
We couldn't possibly understand what a "Push Button" is like those smart C
folks can, huh? And don't get me started on "frames"....

LOL, it's all a matter of what you are most used to.

In VB it's normally termed a 'command button' and prefixed with 'cmd' and it
makes sense to me to stick with the standard conventions in this case.  The
only thing I've ever called a 'push button' is in reference to a telephone
and in that case the individual 'push buttons' don't typically start an
action unless it's the last one of a long sequence and that image just
doesn't mesh with a command button.  Using just 'button' seems too generic
and I always want to ask 'what kind of button' when I see it being used.
Mostly habit I'm sure.

What would you call a Frame?  A Group Box?  It's not a box - it's flat, and
while it does group things that doesn't even hint to me of having a border.
Calling it a 'frame' immediately brings to mind a common picture frame which
provides a border around one or more items and sets them off from the
surroundings and makes perfect sense to me.

Actually it's a matter of what you learned first. I learned Windows
programming in C.

Yes, because that's what they were called long before VB hit the scene, and
it's also what the Windows SDK calls them, which I accept as canon. I've
only grudgingly accepted the term "text box" as opposed to "edit control" to
be perfectly honest.

Show quote Hide quote VB has always had its own sense of , for lack of a better term, "VBness".
Even when I was a C/SDK bigot I never minded that VB was, ah... VB. It
helped to separate the worlds. One often got into trouble not because VB was
NOT like other languages/platform, but because one made assumptions that it
WAS like another language/platform.

I have to side with Bob on this one.

[And how about those 'Panels'? Was that a great idea or what? <g>]

-ralph

Show quote Hide quote And I disagree completely. I think this separation was one of the main
reasons that VB was always seen as a toy language. It made it that much
harder for a VB person who wanted to step "out of the box" to wade into SDK
documentation since terms were different. It's like, "In C or ASM or Pascal
we call it an 'injury,' but in VB we call it a 'boo-boo.'"

ROTFLMAO

I like "ouchy" myself! <g>

Show quote Hide quote Also a valid point and one that has been argued over the years. But one
which does become 'subjective' at some point. Part of its charm, or part of
its unsavoriness?

If you were around back then, remember the 'fight' over the size of an
'Integer'? (a topic taken from another post) Can you imagine the screams, if
you had gotten your wish and VB would have 'renamed' Text Boxes and Frames
with the release of VB4. <g>

Even at my height of bigotry, and I hid my VB books out of embarrassment, I
never really considered VB a 'toy language', it was a interesting fast
development environment with some 'missing' features. <g>

But the argument, of course, is mute now. VBc is gone. And VB.Net is
definitely in the mainstream. We can all cry 'injury' in harmony now.

-ralph

4furNDeRVn***@arkansas.net
pet peeve mode: it may be moot but hardly seems mute

I suppose that depends on your definition of mainstream. 

Show quote Hide quote LOL

Poor choice of word. I guess I meant - cast in the image of C-ness like the
rest of the CLR. <g>

-ralph

Given that it is C# with a thin coat of VB paint I can definitely agree with
that!

Well, if you define it as "supported"....

True, as opposed to "popular" or "used" or "serving a purpose"....

I was going to add "filling a niche" but from what I've seen it does fill a
niche... people who are embarassed about using VB but don't have the ability
to use C.

Show quote Hide quote At first, I would tend to agree with Bob and recommend a control array.
However, my personal preference is to use a Select Case instead of the Tag
option.
(No significant reason, primarily just my preference. I like to be able to
"see" exactly what is going on when I look at the code instead of having to
query the property of each control.)
I might write the handler like so:
'--------------------------------------------------------
Private Sub btnScale_Click(Index As Integer)
    Dim ScaleOption As Long 'Or whatever datatype required

    Select Case Index
        Case 0
            ScaleOption = SCALE_0116PLANS
        Case 1
            ScaleOption = SCALE_0132PLANS
        Case 2
            ScaleOption = SCALE_0332PLANS
    End Select

    Call modScales.setImperialScale(ScaleOption)

End Sub
'--------------------------------------------------------

After a little more thought, and noting your original comment...
"I have a BUNCH of  buttons that all do pretty much the same thing"
This might suggest that a different approach might be in order.
If you do indeed have a "bunch" of buttons that call the same method, then
you might be better off looking into some sort of list. This could be a drop
down combo list, Option buttons, or the like.
Then you would have one "Go" button. In the button's Click event, you could
query the appropriate list for the required value and set it similarly to
above.
Say you use a combo list, then instead of a "BUNCH" of button controls, you
have 1 Command Button and 1 ComboBox. If you want to add or remove options
in the future, then the changes are pretty easy with no modification to the
GUI required. IMHO this would be much more flexible, easier to maintain, and
easier on the end users.

Gerald

<cut>
my preference might be the array I also mentioned; that way the Index for
the command button can be mapped directly to the appropriate constant.  If
the values permit you could also make the Index of each command button in
the control array match the value of the constant.  There's lots of ways to
approach almost any problem.

You could even drop the command button and respond directly to the click
event of a listbox or combobox.

Show quote Hide quote Or to take 'butt-ugly' to another level why not use an enum...

Enum E_SCALEPLANS
   SCALE_0116PLANS
   SCALE_0132PLANS
   SCALE_0332PLANS
End Enum
#If 0 Then   ' preserve case
    Dim SCALE_0116PLANS,  SCALE_0132PLANS,  ...
#End If

Private Sub cmdScale_Click(Index As Integer)
    Call moScales.setImperialScale(Index)
End Sub

Public Function setImperialScale(byval iScale As E_SCALEPLANS) ....
    ' in here while debugging you would see "SCAL_0xxxxPLANS"
End Function

Ralph wrote:
[snip]
Ten years of writing VB and still there are new tricks to learn. Thanks
for that one!

Show quote Hide quote Yup, agree on all counts.
When I was reading the original post, I had this vision of a large form with
a large array of buttons. Not usually what I would consider user friendly.
But heck, I haven't seen it, so maybe it makes perfect sense given the task
it's designed to perform.
I think any of the suggestions are good recommendations to address the OP's
original concern.

BTW: Patrick, nice to see another of the uStn fold hanging around here.
Welcome.

Gerald

Gerald Hernandez wrote:
Thanks, Gerald.  <"It's a Small World" playing in the background>

Basically, what we've done here is to reproduce the functionality
of MicroStation's old "tutorials."  I've got a multi-page control
with an image background on each page representing another
facet of our drawings.  The buttons are scattered all over the
image, adjacent to the element they're indicating, with leaders
pointing their respective elements.  It's an old concept, but
people sure do respond well to the visual approach.

See ya in viecon.

Command Button Sequence
Avoid Overflow!
3 dimenional control array
populating combobox
Update Workstations with new executable
Need to know when a process is exited
form_load parameters - novice
debugging vb6 activex dll under apache/tomcat
Best way to have a subroutine modify more than one variable
Expot datas in to excel sheet