Why this no work?

[Herfried K. Wagner [MVP]]

That is, I have a form with two buttons on it. In button1 I have this code:

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click

MsgBox("Button1 has been fired")

End Sub

In button2 I have this:

Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button2.Click, Button1.Click

End Sub

When I click on Button2 nothing happens.

What would you expect to happen? There is no code added in the event
handler shared between 'Button1' and 'Button2'.

 

[Woody Splawn]

Tom, Thanks for responding.

Woody: Is there a chance it is working as "defined" ?

It is possible. If so, I'd like to find out. That's why I started this
thread<g>. If it is working as designed what do I need to do in order to
change the value of a field on one tab from code in another. Remember, that
the problem seems to only manifest itself when the field is bound. If it is
not bound to a field in a table, no problem. Maybe I need to do more than
change the value in the field on the winform, maybe I need to change the

I also think it is practical to "wait" until some
unspecified time when another version is released... particularly if the new
version operates the same way because "that's what it does."

Not very practical from the client's point of view. I (they) need things to

can you narrow it down to
some code that illustrates the problem? Can you do this without using
Infragistics controls so that we could observe it happening?

As I believe I've mentioned elsewhere the same problem exists in a regular
Microsoft textbox. Unless there is something unique to my machine or form,
which I don't believe there is, it should do the same on yours. The problem
manifests itself when the field is bound.

trim out whatever you can while still generating the
behavior you've mentioned

I believe (I think) I have done this. It should be reproducible by others
as best I can tell.

 

[Woody Splawn]

It is possible that it's working as designed but If so I need to find out.
If it is working as designed what do I need to do in order to change the
value of a field on one tab from code in another. Remember, that
the problem seems to only manifest itself when the field is bound. If it is
not bound to a field in a table, no problem. Maybe I need to do more than
change the value in the field on the winform, maybe I need to change the
value in the underlying dataset. I don't know.

As I believe I've mentioned elsewhere the same problem exists in a regular
Microsoft textbox. Unless there is something unique to my machine or form,
which I don't believe there is, it should do the same on yours. The problem
manifests itself when the field is bound. When the field is not bound, no
problem.

 

[Tom Leylan]

Remember, that the problem seems to only manifest itself when the field is
bound. If it is not bound to a field in a table, no problem.

That is precisely why I suspect it is working fine.

Maybe I need to do more than change the value in the field on the
winform, maybe I need to change the value in the underlying dataset.
I don't know. You tell me.<g>

I've never worked with bound controls. My suggestion is that you look into
what behavior "binding" promises. I would guess that it is reflecting the
property of the underlying data value in your textbox... I'd also guess that
is what binding is supposed to do. If the data value and the textbox were
permitted to get out of sync what good would it do anybody looking at the
textbox?

As I believe I've mentioned elsewhere the same problem exists in a regular
Microsoft textbox. Unless there is something unique to my machine or form,
which I don't believe there is, it should do the same on yours. The problem
manifests itself when the field is bound.

You mentioned it and there is no doubt that it isn't limited to your setup.
I don't have a bound control to test it on and besides mine might be
implemented correctly and I wouldn't see the "problem."

I believe (I think) I have done this. It should be reproducible by others
as best I can tell.

You didn't quite... you introduced "a second tab" and that only complicates
things (including debugging.) "If you eliminate the impossible, whatever
remains, however unlikely is the truth." (Sherlock Holmes)

Test only with MS controls, move them off the tab and don't introduce a
button to set off the event. The way you have it now it could be the text
control, the infragistics control and the text control, the project, data
binding in .Net, the button event, blah, blah... narrow it down to 5 to 10
lines of code and watch it happen in the debugger. Print the textbox value
and the underlying data value. Try setting one, then the other.

I think you'll find it works to spec.

 

[Woody Splawn]

What would you expect to happen?

You may think I'm trying to be funny but I'm not. Fergus said, "You can

use the same handler for more than one Button". Given that, I would expect
that when you clicked on Button2, button1 would fire since in button2 it
says "Handles button1, Button2". Apparently this is not what he meant.

However, I have discovered that if I put the following in button2 button1
will fire

Button1.PerformClick()

All of that said, using the above code, I can fire logic in Button1 from
Button2 but if button 2 exists in another tab the value of the field in tab1
will not change as it does when you fire the same code by actually clicking
on button1. Again, this only happens when the field is bound. You should
be able to reproduce it on your machine.

I do appreciate your help and the help of others here on the newsgroup. I
hope you will stay with me to a clairification of what's happening and a
solution for how to change the value in a textbox on tab A from code in Tab
B. Pretty common thing to do when you stop to think about it.

 

[Woody Splawn]

you introduced "a second tab" and that only complicates

things

The problem only manifests itself when there is more than one tab.

If you never use bound controls then I guess I need to look elsewhere for a
solution.

Thank you for what you have done.

Anyone?

 

[Tom Leylan]

The problem only manifests itself when there is more than one tab.

If you never use bound controls then I guess I need to look elsewhere for a
solution.

Woody, Woody... you're underestimating me. I've never built a bridge
but if you start building one with matchsticks I am qualified to say "that
probably won't work",

But seriously handle it your way, maybe there is a "tab/control bug" of some
sort. I'd be willing to bet there isn't but I could be wrong. When you
find out what it is post the answer here.

 

[Woody Splawn]

Woody, Woody... you're underestimating me.

Tom,

I'm not trying to be smart but I honestly don't know what you're talking
about. You said you never use bound controls. What am I supposed to think?
I feel like because I don't use the right syntax or because I stumble in
some other minor way I am underestimated too. True, I'm somewhat new to VS
but I've been doing this (application design) for a long time. I don't know
all the right words unique to VS but I understand many of the concepts.
What's more fundamental than updating a bound field on a winform, even if
you are trying to do it from another tab? I mean Honestly!

When you find out what it is post the answer here.

It sounds like you're saying "Figure it out for yourself". If so, with all
due respect, what are these news groups for?

I don't mean to underestimate you or anyone else. If I have, I appologize.
I feel like what I am asking are real basic, fair, questions.

 

[Tom Leylan]

What's more fundamental than updating a bound field on a winform, even if
you are trying to do it from another tab? I mean Honestly!

Not much I suppose. But that is exactly why it is so unlikely to be some
odd control-on-a-tab "bug" it would surely show up in a search of Google if
it is a) a commonly done thing and b) didn't work. I use that simple test
for my code all the time... saying simply "this is too common, somebody
would have reported it, it must be my code." And it often is!

It sounds like you're saying "Figure it out for yourself". If so, with all
due respect, what are these news groups for?

In my mind newsgroups are a "resource" but that doesn't mean that people
stop doing whatever they are doing and whip up a solution for every
question. Did you stop working on your project in order to answer
somebody's question?

It isn't unreasonable to conclude because nobody popped in with "yeah my
does that too" or "no way" that none of the binding experts have any idea
why your combination of things is behaving the way it is. Herfried even
asked what that control was? I read your reply but you see that is an
indication that the problem has been made more complex than it needed to be.

Debugging is simply a matter of eliminating suspects... that's why if it
fails on a regular textbox then the message is more easily understood if it
is presented that way. Otherwise you're going to get "contact the
manufacturer of the control" as a response.

I suggested getting them off of the tabs because (if you recall) Fergus
wrote you might be firing an event when you changed the tabs back to look at
the control. Don't you see you aren't getting anywere with it because
you've complicated the problem. The goal is to "simplify."

I don't mean to underestimate you or anyone else. If I have, I appologize.
I feel like what I am asking are real basic, fair, questions.

No apology is necessary. I haven't done a million things but that doesn't
mean I don't know how a million things operate. I can read documentation


Look at it this way... if nothing else and if you posted some 50 or fewer
lines of code that somebody could cut and paste they could verify that it
isn't something in your setup. It isn't I'm sure but... you'd have
eliminated one source and at this point you have eliminated zero sources.

Again I can only state the binding experts don't know why it is acting up.
So I suggest that it isn't. You say it only does this on tabs... I suspect
that something "un obvious" is going on (perhaps in plain sight) but you
aren't seeing it. An event, a typo, a line in the docs that says "this is
how bound controls work" or something like that.

Sorry to be so long winded but I'm almost done. I could start up a test app
and bind a control but frankly I'm not that interested in doing so. Why?
Partly because if it works for me you still haven't eliminated a single
source of "your" problem. If you posted something that produces the error I
wouldn't have to try to manipulate code on my end trying to make it fail
right?

In any case. Whittle it down if nothing else "while" you wait for somebody
to tell you why it is behaving this way. That way when nobody comes up with
the answer (my guess) you will have made some headway.

Does it only do this when the control is bound to SQL Server? Does it do it
if bound to a memory-based dataset? Does it do it if you eliminate the
button click (a potential source of "hey the code in here is wrong")? If
removing the button from the equation still results in the problem then by
all means don't talk about or post the code related to the button. It has
no effect and it complicates your description. Somebody is going to offer
"hey maybe your click event is messed up" and you have to answer "no it
isn't" but you are still no closer...

Got it now? Smile, I'm on your side

 

[Fergus Cooney]

Hi Woody,

This is a long one so bear with me. ;-)

I reckon we'll start with a bit of info about Buttons and their handlers.

Consider this lot.

Private Sub MrSpotty_WhoHe (...) _
Handles Button1.Click
MsgBox ("MrSpotty")
End Sub

Private Sub JanetRadcliffeRichards_GreatBooks (...) _
Handles Button2.Click
MsgBox ("JanetRR") 'If you like that sort of thing.
End Sub

Private Sub HumphreyBogart_DoorSlam (...) _
Handles Button1.Click, Button2.Click
MsgBox ("HumphreyB")
Button1.PerformClick
End Sub

You'll note immediately that <not one> of the names has anything to do
with Buttons or clicking. But these will work!! The name of an event handler
is <totally> arbitrary.

Now you'll see that each Button occurs in two Handles clauses. <This> is
the important bit. It means that two routines will be called when each Button
is clicked.

I can't say what that order it will be, though. In C# it's easy as these
things are set explicitly. In VB it's a lucky dip, I guess. For me, when I
clicked Button1 I got MrSpotty then HumphreyB. When I clicked Button2 it was
HumphreyB and then JanetRR. 'Go figure', as they say.

Button1 and Button2 are completely independant. It is merely coincidence
that they share HumphreyB as a handler. If one is clicked it has no effect of
the other whatsoever. It merely calls the routines that it has in it's <own>
list. When your flatmate comes home with one of his girlfriends, do <you> get
laid as well? (You do? Oh! Ok, that example didin't work then)

Now notice that call to Button1.PerformClick. That's very dangerous. When
Button1 is clicked, MrSpotty is called and then HumphreyB will be called and
that will cause a Click to added to the message queue. Which will call Mr
Spotty and then HumphreyB which will cause ...

I'm surprised that you didn't get caught in a loop when you tried it. I
certainly did. I had to reboot and reinstall Windows, VS and everything. The
things I do for this group!!

[Time out to eat pizza ...]

Well I might not have covered it all but I'm moving on anyway.

======================================
Textboxes and Tabs

I'm a TextBox and I live on a Tabbed Page. Mostly I mind my own business.
Sometimes someone is talking loudly and it puts a thought into my mind and I
ponder it for a while. You can see it in my expression. Then suddenly the
Tabbed Page shouts Atten-Hut!! (Why is it Hut! in the US? we say Shun! over
here). Anyway, this wakes me up and I clear my mind of that pleasant daydream
and bring the appropraite thought into my mind.

Similarly, the Bound TextBox will accept your string and display it while
the Tabbed Page is sleeping. When the page changes it tells the TextBox to
"Smarten Up Laddy! and Look Lively!". Which means going to the DataSource to
get the original value again - and clearing out the temporary one that it was
displaying. What temporary value? Well all TextBoxes have a value field.
DataBound TextBoxes have it and use it, why not?, but they'll make the long
trek to get the proper value when needed.

So here's a test. Set your TextBox in the code and immediately check the
underlying value in the DataSource. If it has changed then I'm talking
rubbish. If it hasn't changed, then maybe I have a point. Because anytime the
TextBox has to refresh (and the reappearance of its home Tab Page is a pretty
good candidate) it will go to the Source and get what it <should> be
displaying.

You say you set the TextBox value. Some last questions

Are you expecting the DataSource to update? Is it doing so? If not, can
you set the DataSource directly? If you do, does your TextBox now display the
correct value?

That's me done. Good luck.

Regards,
Fergus

ps1 You think I'm being silly?? You're right!! It has nothing to do with you,
mind - but it might have a bit to do with the cider that I've been quaffing!
[chortle] ;-)

ps2. I know, I know, who's Janet Radcliffe-Richards. She's a philosopher. What
a mind. What a face. What a babe! Oh, the pain of being born too young.

ps3 I started sober, honestly, but I took time out to make a pizza, and by the
end? Well, I was completely gestunkenflot. So I hope it made sense.

ps4 If I'm wrong my excuse is number 3!! But if what I said makes sense and
turns out correct, then I have a confession to make. I have never used a
databound control in my life! Shock horror, maybe, but I know a fair bit about
this and that and can cobble together something that could be correct. I
advise against matchstick bridges too (except in prison - so little to do!).

 

[Cor]

Herfried,

Seems that you are not hanging around in the Windows Forms groups.
VS.NET isn't buggy, some Windows Forms controls are/were a little bit
buggy.

The word "some" is important in your sentence, but I think that it is mostly
because some are so overloaded in a single control that nobody sees the end
anymore, while it are old ones.

Example "Combobox" and "Listbox"

Or so new that even very simple problems are still in
"File folder dialog control"

But to say that it is impossible, there is almost everytime another way. I
have still not used all controls from Microsoft, so I think there are still
a lot of alternatives if I cannot do it with a control you thought you did
want to use. And sometimes you have to think "is it something the user
wants" or is it becomming a hobby (coloring the tabs on tabpages as sample).

I think that the color possibilities from the newer controls are not
complete, what is of cours normal, you can not expect that someone who makes
something new is able to do all things the world want the first time right.

This last appends to the words of Tom that when there are new ones we have
to go a buggy time again.



Cor.

 

[Cor]

Hi Fergus,
The solution, I had that idea also, but we see to few code to be sure of
that.

Cor

 

[Herfried K. Wagner [MVP]]

The word "some" is important in your sentence, but I think that it is mostly
because some are so overloaded in a single control that nobody sees the end
anymore, while it are old ones.

Example "Combobox" and "Listbox"

Or so new that even very simple problems are still in
"File folder dialog control"

TabControl seems to have bugs with databound controls.
PictureBox seems to have problems displaying icons (design time
vs. runtime).
Labels had problems displaying the text in some cases.
ListView + images doesn't work with Visual Styles.
MonthCalendar does not work correctly with Visual Styles.
ToolBar, ListView, ProgressBar etc. are limited in their functionality.
....

I think that the color possibilities from the newer controls are not
complete, what is of cours normal, you can not expect that someone who makes
something new is able to do all things the world want the first time right.

Changing colors is often not really necessary, but sometimes it's useful.

This last appends to the words of Tom that when there are new ones we have
to go a buggy time again.

Let's wait...

 

[Peter Huang]

Hi Woody,

I can reproduce the problem on my machine.
I think you can workaround the problem by change the value of the dataset
directly.
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
'TextBox1.Text = "ee"
DataSet11.Tables(0).Rows(0)(0) = "ee"
End Sub

I look forward to hearing from you.

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Woody Splawn]

Peter,

Thank you for your suggestion. That was very helpful.

Woody