invoke click on another form 2

[jozino01]

hi, i try to automatically read data from excel table (instead of manual typing data) using existing program.
the issue is how to invoke "click button" on another form.

For I = txtFrom.Text To txtTo.Text
frmLUMBER.cmbSIZE.Text = ws1.Cells(I, 1)
frmLUMBER.cmbGRADE.Text = ws1.Cells(I, 2)
frmLUMBER.txtLOT.Text = ws1.Cells(I, 3)
frmLUMBER.txtVOLUME.Text = ws1.Cells(I, 4)
frmLUMBER.txtMFBM.Text = ws1.Cells(I, 5)
?????frmLUMBER.cmdADD_Click?????
Next I

any sugestion, please?

 

[Andrzejek]

Try:

For I = txtFrom.Text To txtTo.Text
    With frmLUMBER
        .cmbSIZE.Text = ws1.Cells(I, 1)
        .cmbGRADE.Text = ws1.Cells(I, 2)
        .txtLOT.Text = ws1.Cells(I, 3)
        .txtVOLUME.Text = ws1.Cells(I, 4)
        .txtMFBM.Text = ws1.Cells(I, 5)
        [blue].cmdADD.Value = True[/blue]
    End With
Next I

Have fun.

---- Andy

 

[jozino01]

it works very well, thank you!

 

[BobRodes]

Interesting idea Andy, in effect you're simulating clicking the command button. It never occurred to me that you could do it that way, in fact. However, the underlying concept isn't something that you'd want to use on all types of event handler. For example, you'd have to put some sort of dummy character into a text box to invoke a change event, and then of course ignore the second change event that occurs when you take it out again.

So, another way to invoke event handlers is by simply calling them. (jozino, you were on the right track!) They're procedures just like any other, and so can be called just like any other. Now, the problem in this case is that you're trying to call the handler from another form, and event handlers are private by default. You can handle this in either of two ways: put a public sub in the target form that calls the click event procedure, and call that from the calling form, or simply make the click event procedure public and call it directly.

To illustrate this, put two forms in a project. Put a command button on each. Now, for the first technique, on form2, put the following code:

Private Sub Command1_Click()
MsgBox "click"
End Sub

Public Sub ClickCommand1()
Command1_Click
End Sub

On Form1, put the following code:

Private Sub Command1_Click()
Form2.ClickCommand1
End Sub

Private Sub Form_Load()
Form2.Show
End Sub

Now, for the second technique, on form2, put the following code:

[COLOR=red]Public[/color] Sub Command1_Click()
MsgBox "click"
End Sub

On Form1, put the following code:

Private Sub Command1_Click()
Form2.Command1_Click
End Sub

Private Sub Form_Load()
Form2.Show
End Sub

Now, I don't mean to say that you shouldn't use Andy's solution. I might even use it myself, now that I know it works! But I believe it's important to know all this other stuff, because it lets you invoke any kind of event handler on a different form, not just the command button click event.

Bob

 

[HughLerwill]

I always thought that making procedures as local as possible was desirable and that calling event procedures and making them Public was undesirable. It is not always possible to avoid such use but in this case it is.

To me Andy's .cmdADD.Value = True is just the standard way to do it.

 

[Andrzejek]

WOW, Bob. I am surprised – I showed you something simple and basic that you did not know. Over the years on Tech-Tips I kind of got the idea that you do know A LOT more than me (which I still fell that’s the case) and now this

I try to avoid clicking the button from other Form, but sometimes that’s the easiest way to accomplish something. One can even argue about jozino01’s technique of moving data into controls to Add and, probably, not even showing the Form. But if it works – hey, that’s his/hers app.


Have fun.

---- Andy

 

[BobRodes]

Well, Hugh, along with the idea of "scope creep" there is also the idea of architectural consistency. As far as I'm concerned, balancing the two is important. So, I'd say it's a matter of context. If you are calling a lot of event handlers from another form, you might not want to find different ways to call all of them because it will be harder for someone maintaining your code to understand. Of course, calling event procedures in the first place can be hard to understand, so I take your point. You can always put your code in another place and have both the handler and the calling proc call that place. But I wouldn't say that it's wrong not to do it that way. Again, it's a matter of clarity and control.

So, I disagree with you that Andy's way is "just the standard way to do it." To me, it's just another tool in the box.

Bob

 

[BobRodes]

By the way, I personally would consider putting the code in the event handler into a public proc and calling it from both the place where I called the event handler and the event handler itself. My second choice would be to use the first technique that I described, and my last choice would be to make the event handler public.

Bob

 

[HughLerwill]

I alway thought that it was desirable to simplify and reduce your code to the minimum. It is not always possible to do that but in this case it is.

 

[JoeAtWork]

I personally would consider putting the code in the event handler into a public proc and calling it from both the place where I called the event handler and the event handler itself

That's the way I do it. I really don't like the idea of invoking an event procedure because it obscures the purpose of that procedure. The Click event is supposed to occur when somebody clicks on the control - and that's it. Just because it happens to call a Save routine in turn does not mean it should become the defacto "procedure to save".

One of the pitfalls of calling an event procedure because "it happens to do what I want" is that later on the event's code might change, and now it is doing extra things that shouldn't happen except if the actual event is happening. Imagine you write some sort of batch code to import hundreds of records at a time. You might loop through each record, calling cmdADD_Click each time - and it works. Six months later, the people who use the form want a confirmation displayed before saving, e.g. "Are you sure you want to save?". Perfectly reasonable, you implement it, and your users are happy. Until - they run the batch import, and have to click OK a few hundred times!

For similar reasons I don't like the cmdADD.Value = True trick. Leave the control events for the users!

I alway thought that it was desirable to simplify and reduce your code to the minimum

I find maintanability, reusability, and readability beats code minimism. Not that they are necessarily uncompatible. Minimism often helps readability (unless you over-do it, like with 2 letter variable names). But maintainable and reusable code usually requires more than the "bare minimum to get it to work".

Oh my, I seem to have written another long winded post!

 

[harebrain]

I agree with JoeAtWork here: simplification is often at odds with code minimization. When that occurs, I would prefer simplification over almost any other goal.

 

[strongm]

>That's the way I do it.

Me too, generally.

 

[BobRodes]

<I find maintanability, reusability, and readability beats code minimism. Not that they are necessarily uncompatible.

Thanks Joe, that perfectly explains my point of view.

Bob

 

[jozino01]

great discussion, guys. i like this site, it's been very helpful.
there is not one solution which would fit to every case.
maybe cmdADD.Value = True isn't the best solution considering all programming theory rules, but it works perfectly in my case.
this solution allows to keep existing manual entering data to an invoicing program and also to get data directly from the source (excel) without user input (no need to click add/ok after each line). cmdAdd_Click already contains data validation and an user has the option to modify data before going to a new invoice.
thanks everybody for your input!

 

[BobRodes]

<isn't the best solution considering all programming theory rules, but it works perfectly in my case.

Would that I had such confidence in MY future.....

 

[jozino01]

well, it doesn't matter in my case, i am officially an accountant

 

[BobRodes]

Aha. What Douglas Adams (in "Dirk Gently's Holistic Detective Agency") refers to as an "SEP." LOL