By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,611 Members | 1,629 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,611 IT Pros & Developers. It's quick & easy.

Why this no work?

P: n/a
I have a winform with a tab on it. On tabA I have a field called
nbrBalDue. In the Click event of a button on tabA I have the following code

Me.nbrBalDue.Value = 66

When I click the button evertyhing works as expected. The BalDue field now
has a value of 66.

However, if I put another button on TabB with the same code in it and click
it, BalDue does not get updated to 66.

Could somone explain why?

Nov 20 '05 #1
Share this Question
Share on Google+
33 Replies


P: n/a
* "Woody Splawn" <wo***@splawns.com> scripsit:
I have a winform with a tab on it. On tabA I have a field called
nbrBalDue. In the Click event of a button on tabA I have the following code

Me.nbrBalDue.Value = 66

When I click the button evertyhing works as expected. The BalDue field now
has a value of 66.

However, if I put another button on TabB with the same code in it and click
it, BalDue does not get updated to 66.


What's the type of the field? A textbox?

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>

Improve your quoting style:
<http://learn.to/quote>
<http://www.plig.net/nnq/nquote.html>
Nov 20 '05 #2

P: n/a
Actually its an Infragistics UltraNumeric Editor.
Nov 20 '05 #3

P: n/a
Hi Woody,

You can use the same handler for more than one Button.

Sub Button_Click (...) Handles ButtonA.Click, ButtonB.Click
Me.nbrBalDue.Value = 66
MshBox ("nbrBalDue is now " & Me.nbrBalDue.Value.ToString)

Have a go that way and see if it still fails to update.

Next, you say that nbrBalDue is on tabA. When you click the Button on
tabB, presumably nbrBalDue is hidden. Therefore you can't see it until you go
back to tabA. And this suggests that when you show the Tab, nbrBalDue is being
reset to some default value.

Regards,
Fergus
Nov 20 '05 #4

P: n/a
Hi Woody,

This might be bad news. Touf has been having a very similar problem
whereby CheckBoxes on a TabPage are being reset.

|| I've a Tabcontrol with many tabpages, in each one I've a
|| checked listBox. The problem is that when I check items
|| in listBox and go to an other page I lost the check (when
|| I return to my tabbpage I find all items Unchecked)

He uses VS 2002, .NET 1.0. Which version are you using?

I can't test this as I have v2002 as well. It might be useful to post
something that those with v2003 can test with.

Regards,
Fergus
Nov 20 '05 #5

P: n/a
Hi Woody,

What is the Infragistics UltraNumeric Editor?
Did the problem persists with other control in VS.NET, e.g. textBox?
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.

Nov 20 '05 #6

P: n/a
* "Woody Splawn" <wo***@splawns.com> scripsit:
Actually its an Infragistics UltraNumeric Editor.


Maybe Infragistics provides a support database or their own
forums/newsgroups. Does the problem even occur with other controls?

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #7

P: n/a
Which version are you using?

I am using version 2003

I have experienced similar problems. But only on fields that are bound.
Are his fields bound?

That is, I have a Winform with tabs on it. In TabA I have two fields. When
the user enters data in field A, a calculation is run to put data in field
B. This code is run from the Validating event of field A. If I move from
field A by tabbing or clicking on another field on the same tab, no problem.
However, if I enter data in field A and then click on Tab B and then return
to Tab A, the value in field B of Tab A is not updated.

This only happens when fields are bound. I can do the same thing with
unbound fields and there is no problem.

Nov 20 '05 #8

P: n/a
Hey Peter!
What is the Infragistics UltraNumeric Editor?
It is the Numeric Editor object provided by Infragistics Software. They are
the leader in 3rd party software for VS I believe.
Did the problem persists with other control in VS.NET, e.g. textBox?


Yes. When I use a regular microsoft text box I have the same problem. It
should be noted however that the problem only exists when the the field is
bound. When the fields are unbound there is no problem. When unbound, both
the Infragistics and Microsoft components work. In my case I have the field
bound to a column in a SQL Server table.

What do you think is happening?



Nov 20 '05 #9

P: n/a
Thanks for responding Herfried.
Does the problem even occur with other controls?
Yes, please see my response to Peter.
Maybe Infragistics provides a support database or their own
forums/newsgroups


They do but this is one of the classic problems with Visual Studio. I am
glad to be using the product and am not bashing it but from the developers
point of view my frustration is as follows.

MS does not provide tools for the IDE that are sufficient for this
developer. Even the simplest things can not be done without making a
federal case out of it. I feel I have no choice but to turn to third party
products. Infragistics seems to be about the best, at least to me.
However, when you (the developer) have problems, it allows MS to point the
finger at Infragistics and Infragistics to point the finger at MS.
Frustrating. Not possible to get an answer from a singel source. Oh well.
Just part of the day and age I guess.

To me it's all about "Big Ships and Tugboats". Microsoft is a big ship and
has their eye on the sea. It leaves the little things, like the IDE, to the
tugboats. But to the developer, both are important. The ship can't sail
till you get it out of the dock.

Additionally, since I'm on my high soapbox <g>.

Microsoft could benefit tremendously from the PowerBuilder concept of a
DataWindow. It is a patended product so this is not likely. I see so many
circumstances in VS where you have to do things in a non uniform way. For
example, the way you deal with validation with regard to fields on a winform
is completely different than how you do it if you are working with a grid.
The grid method is much simpler since it deal with each entity (each field)
as part of a whole. However, the bottom line on it all is that Microsoft
has the market share and so there's nothing to talk about. I'll eat my
Visual Studio wheaties and like it too. Never the less, these are my
feelings.

Soapbox dismantled.


Nov 20 '05 #10

P: n/a
* "Woody Splawn" <wo***@splawns.com> scripsit:
Thanks for responding Herfried.
Does the problem even occur with other controls?


Yes, please see my response to Peter.


OK.
Maybe Infragistics provides a support database or their own
forums/newsgroups


They do but this is one of the classic problems with Visual Studio. I am
glad to be using the product and am not bashing it but from the developers
point of view my frustration is as follows.


IMO VS.NET and the .NET framework are still in an "early state of
development". Even .NET 2.0 will only be a small step. The big changes
will be done in the framework for Longhorn (VS.NET Orcas I think).
Nevertheless there will be some improvements in the next version:

<http://msdn.microsoft.com/vbasic/whidbey/>

Whidbey will also come with some new controls. In Whidbey data access
will be much easier, have a look at the video linked on the VB.NET
Whidbey information page above.

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #11

P: n/a
Thanks for the pointer to WhidBey. Verry interesting. This is why I am on
the MS bandwagon. This is where all the action is.

With regard to the original question. Do you have any idea why things are
not working?

Nov 20 '05 #12

P: n/a
* "Woody Splawn" <wo***@splawns.com> scripsit:
Thanks for the pointer to WhidBey. Verry interesting. This is why I am on
the MS bandwagon. This is where all the action is.

With regard to the original question. Do you have any idea why things are
not working?


I don't know it but IMHO most of the controls won't be used any more when
Longhorn is released. I seems that this is the reason why the controls
are "buggy" sometimes...

;-)

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #13

P: n/a
"Woody Splawn" <wo***@splawns.com> wrote...
Thanks for the pointer to WhidBey. Verry interesting. This is why I am on the MS bandwagon. This is where all the action is.

With regard to the original question. Do you have any idea why things are
not working?


Woody: Is there a chance it is working as "defined" ? I find it unlikely
that this would be completely broken right out of the box without a bunch of
people knowing about it. 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."

I don't know that I can be of a lot of help but 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?

Try to elminate the "second tab" and just add a second button to the first
tab, in other words trim out whatever you can while still generating the
behavior you've mentioned. The more things you add the more obscure the
cause is likely to become.

Tom
Nov 20 '05 #14

P: n/a
Cor
Herfried,

I don't know it but IMHO most of the controls won't be used any more when
Longhorn is released. I seems that this is the reason why the controls
are "buggy" sometimes...


???

Cor
Nov 20 '05 #15

P: n/a
* "Cor" <no*@non.com> scripsit:
I don't know it but IMHO most of the controls won't be used any more when
Longhorn is released. I seems that this is the reason why the controls
are "buggy" sometimes...


???


Windows forms will be "replaced" (even if they don't use this term)...
Have a look at the links Thomas Scheidegger [MVP] posted some days ago
(an "ANN" message).

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #16

P: n/a
Cor
Herfried,

I dont find the vs version 1.1 or the vs.studio 2003 buggy,
we see seldom really bugs here.

I can remember me this last month only one in a Zip file.
But that one you never saw, so you did not even seen that one.

:-))))))))))))))))))))))

Cor
Nov 20 '05 #17

P: n/a
"Cor" <no*@non.com> wrote...
I dont find the vs version 1.1 or the vs.studio 2003 buggy,
we see seldom really bugs here.


Absolutely... and besides anything "new" is likely to have new bugs. There
is no "fewer bugs" release being planned. If MS knew there was a bug and it
was easy to fix my guess is it wouldn't be a bug.

Nov 20 '05 #18

P: n/a
* "Cor" <no*@non.com> scripsit:
I dont find the vs version 1.1 or the vs.studio 2003 buggy,
we see seldom really bugs here.

I can remember me this last month only one in a Zip file.
But that one you never saw, so you did not even seen that one.


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.

;-)

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #19

P: n/a
Fergus,

I've tried your suggestion but it doesn't work for me.

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.


Nov 20 '05 #20

P: n/a
* "Woody Splawn" <wo***@splawns.com> scripsit:
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'.

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #21

P: n/a
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
value in the underlying dataset. I don't know. You tell me.<g>
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
work now<g>
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.



Nov 20 '05 #22

P: n/a

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.



Nov 20 '05 #23

P: n/a
"Woody Splawn" <wo***@splawns.com> wrote...
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."
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.


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. :-)

Nov 20 '05 #24

P: n/a
> 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.

Nov 20 '05 #25

P: n/a
>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?
Nov 20 '05 #26

P: n/a
"Woody Splawn" <wo***@splawns.com> wrote...
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.


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.
Nov 20 '05 #27

P: n/a
> 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.


Nov 20 '05 #28

P: n/a
"Woody Splawn" <wo***@splawns.com> wrote...
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 :-)

Nov 20 '05 #29

P: n/a
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!).
Nov 20 '05 #30

P: n/a
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.

Nov 20 '05 #31

P: n/a
Cor
Hi Fergus,
The solution, I had that idea also, but we see to few code to be sure of
that.
:-)
Cor
Nov 20 '05 #32

P: n/a
* "Cor" <no*@non.com> scripsit:
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"


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...

--
Herfried K. Wagner
MVP VB Classic, VB.NET
<http://www.mvps.org/dotnet>
Nov 20 '05 #33

P: n/a
Peter,

Thank you for your suggestion. That was very helpful.

Woody
Nov 20 '05 #34

This discussion thread is closed

Replies have been disabled for this discussion.