Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / Modules / DAO / VBA / January 2007

Tip: Looking for answers? Try searching our database.

Calling a Sub Procedure Within a Form Based On a Variable

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Regulator - 07 Jan 2007 04:03 GMT
I am trying to call a sub procedures based on the current textbox.  The
situation is this; my database receives input from a scale and places the
weights directly into the textbox with the focus.  The scale communicates
using MsComm's OnComm event. However, this does not run the
Textbox_AfterUpdate procedure that needs to be run (I don't know why).  Since
there are many textboxes that receive weights from the scale, I need it to
run the correct AfterUpdate procedure.

So far I have tried :

dim strTextbox as String
strTextbox = me.ActiveControl.Name & "_AfterUpdate"
call strTextbox

That did not work because access requires a sub procedure so I tried:

dim strTextbox as String
strTextbox = me.ActiveControl.Name & "_AfterUpdate"
application.run strTextbox

This does not work; I guess, because the form is not a public class and the
procedure also is not public.

I might also add that the form that gets the input is a subform.

I need to solve this problem one of two ways.  1, the text box recognizes
that it has been updated and therefore, runs the appropriate sub
automatically; or 2, the OnComm can call the appropriate AfterUpdate
procedure.  Any help will be greatly appreciated.
Douglas J. Steele - 07 Jan 2007 12:30 GMT
Why not have a generic routine, and pass it information such as which
textbox is relevant? (Actually, you should be able to use the
Screen.ActiveControl or Screen.PreviousControl properties to determine that,
so passing an argument might not be necessary)

Make the generic routine a function, and then set the AfterUpdate property
of each of the text boxes to that function. Remember that you can set the
properties for multiple text boxes at once if you've selected all of the
text boxes, and then go to the Properties dialog.

Signature

Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)

>I am trying to call a sub procedures based on the current textbox.  The
> situation is this; my database receives input from a scale and places the
[quoted text clipped - 27 lines]
> automatically; or 2, the OnComm can call the appropriate AfterUpdate
> procedure.  Any help will be greatly appreciated.
Regulator - 07 Jan 2007 16:46 GMT
A generic function has a couple of problems with it.  1, the after update for
each textbox does different things.  Some check to make sure that the scale
was zeroed and at a gross 0.  Others record the weight displayed and check to
make sure that it is within the acceptable tolerance which is also different
for each textbox.  Then other textboxes make sure that the scale is tared at
0 on a net weight.  Also to make it go to a general function and go through a
select case statement for each text box would be horrendous considering there
are 12 separate text box all with their unique functions.  This database will
unfortunately be run on P3 450 mhz computers (company to cheap to upgrade
production computers) so saving processing speed is very important thus I
would like to minimize calls to other functions and case statements.

If I misunderstood what you were trying to tell me, please let me know.  I
am thankful for the quick reply.  If I can get the program to call the
correct afterupdate function directly all my problems will be solved.

Thank you very much for your reply.

Regulator

> Why not have a generic routine, and pass it information such as which
> textbox is relevant? (Actually, you should be able to use the
[quoted text clipped - 37 lines]
> > automatically; or 2, the OnComm can call the appropriate AfterUpdate
> > procedure.  Any help will be greatly appreciated.
Douglas J. Steele - 07 Jan 2007 17:55 GMT
I don't see why "a select case statement for each text box would be
horrendous". You've already (presumably) written the code for each of the 12
separate text boxes. Worst case is that you leave the code you've already
written, and use:

 Select Case Screen.ActiveControl.Name
   Case "Text1"
     Call Text1_AfterUpdate()
   Case "Text2"
     Call Text2_AfterUpdate()
   Case Else
     MsgBox "Sorry: I don't what to do for " & _
       Screen.ActiveControl.Name
   End Select

(Better, of course, would be to copy the appropriate code from each of the
12 routines into the appropriate Case blocks)

The overhead of the intermediary routine should be minimal.

Signature

Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(no private e-mails, please)

>A generic function has a couple of problems with it.  1, the after update
>for
[quoted text clipped - 71 lines]
>> > automatically; or 2, the OnComm can call the appropriate AfterUpdate
>> > procedure.  Any help will be greatly appreciated.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.