Can module know what triggered it?

[Willem!]

Hi, I am a bit confused here, somehow I cannot see the way how I could do this.

I have a form where you can enter several numbers, then you can press on button1 or button2 which both start the same module that processes the entered data.

The button1 and button2 calculations are almost same, the only difference is that when you press button1 the module should fill another recordset in the module than when you press button2.

Below the code:

 If someBoolean Then    
    Select Case Valuta        
        Case "EUR" 
            Set rsInput = db.OpenRecordset("TotalEUR")      
        Case "USD"
            Set rsInput = db.OpenRecordset("TotalUSD")  
    End Select

Else    

    Select Case Valuta      
        Case "EUR"         
            Set rsInput = db.OpenRecordset("QueryTotalEUR")     
        Case "USD"       
            Set rsInput = db.OpenRecordset("QueryTotalUSD") 
     End Select

End If

Now my question is, how can I refer to 'someBoolean' from the module to a boolean variable in the form? Is it possible to 'know' in the module which button triggered the module?

Or should I just make a invisible checkbox which registrates what button is pressed...

Cheers,
Willem

 

[KenHigg]

To be honest, it seems the best thing to do here is to have two seperate routines. However, I don't see why you couldn't pass your routine a variable that can be evaluated to determine which part of the routine to execute...

 

[RCurtin]

You could just pass the recordset that you want updated as a parameter or arguement to the module.

Public function yourFunctionName( calculation as String)
    If calculation = "button1" Then    
    Select Case Valuta        
        Case "EUR" 
            Set rsInput = db.OpenRecordset("TotalEUR")      
        Case "USD"
            Set rsInput = db.OpenRecordset("TotalUSD")  
    End Select

Else If calculation = "button2" Then      

    Select Case Valuta      
        Case "EUR"         
            Set rsInput = db.OpenRecordset("QueryTotalEUR")     
        Case "USD"       
            Set rsInput = db.OpenRecordset("QueryTotalUSD") 
     End Select

End If

Then when you call the function from button1:
yourFunctionName( "button1").

Obviously change the names of the variables to something meaningful. Maybe it would be possible for you to pass the name of the table or recordset as a parameter:

Public function yourFunctionName( myRS as String)
    If calculation = "button1" Then    
    Select Case Valuta        
        Case "EUR" 
            Set rsInput = db.OpenRecordset(myRS )      
       end select
end function

 

[modest]

use the button's _OnClick event

 

[Willem!]

Guys,

thank you all for your input. I made it work with the solution RCurtin offered!!

superb!

Cheers,
Willem!

 

[KenHigg]

Guys,

thank you all for your input. I made it work with the solution RCurtin offered!!

superb!

Cheers,
Willem!

That was a slick solution...

 

[modest]

Why? You're making more work on the database. It already has built-in event handlers, why not use them?

 

[Willem!]

Well, yeah, that's true, however now that the main code is placed outside the button itself, you're less depending on it.
So, now you could call the module from an e.g. button3 and tell the module you want a 'button1 treatment'.

button3 can be a button on another form on a different page in your main form.

Willem

(or am I completely overseeing something?)

 

[modest]

Flexibility is the key to high-level code, but a problem that people often mistake is that they write their code too flexible. They produce more lines/logic then needed when a simple, timely solution is right at your finger tips.

In my experience, I've hardly ever had to reuse short code. It's faster to just retype it then to look for it and change variable names around. It's the more complicated code that you want to reuse (mine generally consist of some sort of API call). Don't get me wrong though.. if you plan on having 100 buttons then, by all means, use flexible code; but for two buttons, you might not want to.

 

[Willem!]

Hi,
sorry for my late reply (well, it's late where I'm staying at the moment )

You're absolutely right, flexibility is nice, but simplicity at some times even nicer.

In my project I have several buttons (more than 2) that have to start processes which differ slightly from each other. So that's why I preferred the complicated way of doing things, all the important code is clustered at 1 point in the database.

Also if I wanted to make some minor adjustments in the future it is easily to alter the clustered code rather than go by button after button after button changing things.

But I certainly appreciate your critical input, at this forum we should comment as open and honest as possible

Good night!

Willem