|
Then no, you can't do that. You are not on the GUI thread when the Watcher signals the event.
See Here for what to do.[^]
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
Thank you everyone for your help.
|
|
|
|
|
I think I disagree. If you have some prior programming experience, you can easily finish Hello World by noon, and use the rest of the day to discover event handlers; it isn't that hard to stumble on one (timer ticks, serialport received/errors, FileSystemWatcher, etc) at all. Unfortunately the documentation does not clearly state exactly how and when the event handler will execute, and the InvalidOperationException is sufficiently cryptic, so without any help it may be hard to get it working properly before midnight.
|
|
|
|
|
If you aren't using threading (as Pete sugests), then PogoBoy is right - breakpoint the first line in your event handler and single step though. I very much doubt it's the label.Text assignment that is causing the problem, unless threads are involved.
Additionally, go to "Debug" on the Visual Studio menu, select "Exceptions" and make sure everything is ticked - Thrown and Unhandled. That may catch an error earlier, but is a PITA for normal debugging as all exceptions are trapped in the debugger.
A thought occurred - you are running the Debug version of your App, not the Release, aren't you?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
|
|
|
|
|
I would suggest placing a breakpoint on the first line of your button click event handler and then step through your code step by step to find out exactly why the application is exiting. I have a couple hunches, but without better information, I'd be doing nothing more than guessing. You may find that something entirely different than you expect to be happening. (i.e. I don't think your label is the issue.)
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Yes I did this.
It exits exactly on line with Label changing text.
|
|
|
|
|
Most event handlers are completely asynchronous and execute at a point in time unrelated to what your main thread is doing, so it is pretty natural they run on other threads. Examples are: SerialPort.DataReceived, most timer events, FileSystemWatcher events, etc.
You may want and read this[^] for some experimental proof.
And this[^] for a solution.
|
|
|
|
|
I always hear how VB is soooo verbose and sooooo hard on the eyes... Well I have had it with C# this week.
Please explain to me why in the VB.Net code editor you can select a control on a form from the drop down box on the left and then select the method, etc... that you want to write code for from the drop down on the right and get the shell of the code built for you in the code window, or be taken to where it already exists.
...but in C# all you see in the left drop down in the current parent object that you are in (IE: class, form, etc…) and the right drop down box either only shows you a listing of controls on that form, or methods of the class, but NOT a listing of controls placed on the form?
I don’t get it. What is wrong with the way the VB editor works?
You C# guys need to declare a delegate and attach it to a control, blah blah blah...
All the VB person has to do is select and click and we get the darn code done for us.
Oh yeah, and before you start yelling about connecting multiple handlers to an event, all I have to do in VB is add a Handles clause to the end of my event handler to attach the other control(s) and if I am good, I also modify the name of the method to be more generic, and I am DONE!
Grrrrrrrrrr
Done venting now...
|
|
|
|
|
Are you still using the old crap way of event handling? Haven't you heard of weak events? Oh wait "Handles" doesn't handle that. 
|
|
|
|
|
Talk about 'weak events'... I think that pun qualifies
|
|
|
|
|
Totally agree.
Although I'm using more C# than VB.NET I totally agree with Ray, VB.NET editor is superior as far as helping you with the code.
It also shows a comprehensive list of events implemented for that particular control.
Not to mention the right arguments types for the event handler.
|
|
|
|
|
Ray Cassick wrote: drop down box on the left
Ray Cassick wrote: left drop down
Ray Cassick wrote: right drop down box
Ray Cassick wrote: a listing of controls placed on the form
Umm, what? I don't follow. Any VB can do, C# can do better.
|
|
|
|
|
well, there are a couple of differences in the way Visual Studio helps the programmer. In VB.NET the class drop-down (on top of the source edit windows) shows its content hierarchically, so one sees a list of the controls, in C# it doesn't do that, it behaves like a simple ComboBox. Maybe the designers just had some spare time or they thought the VB people needed more help?
|
|
|
|
|
Luc Pattyn wrote: ... or they thought the VB people needed more help?
I think you're on to something, Luc. I've never had problems finding methods and events in C# and never used the drop down in VB.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
|
I only recently changed to C# but was not even aware of the IDE capability, then again I am continually amazed at the shortcuts that I don't know of. Just vetting the way another programmer does their work reveals little insights all the time.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
So, not like the alphabetical list at the top of the Properties pane? Which I hardly ever use?
|
|
|
|
|
I finally got around to creating a WinForms solution (VS2008) in VB.net and I don't see what you're talking about -- it looks pretty much the same as a C# solution; except C# solutions/projects don't hide files from me.
|
|
|
|
|
if it is a WinForm project, add some Controls to the Form, and they appear in the drop-down at the top left of the edit window in VB.NET, they don't in C# (I'm using Express Editions here).
VB.NET Express hides files by default, clicking one of the buttons above the solution pane remedies that.
|
|
|
|
|
Luc Pattyn wrote: add some Controls to the Form
Yep, did that.
Luc Pattyn wrote: and they appear in the drop-down at the top left of the edit window in VB.NET
I don't see it... ohhh... that. I don't usually have the Navigation Bar (never heard of it before now) turned on in C#; it seems fairly pointless, trying it on for size now. Yeah pointless, only useful if you define multiple classes in one file -- which you shouldn't do.
And they don't let you turn off the Navigation Bar in VB?! 
|
|
|
|
|
I typically have only one class in a file, and I only use the righthand drop-down, which lists methods and properties. That is quite useful IMO.
I don't remember having ever changed the setting about nav bars, and they are present for me both in VB.NET and C# (Express!)
|
|
|
|
|
I guess you can't blame the language. If the C# editor lacks some features, you should blame the editor. Both languages are different, with pros and cons. I prefer C# for almost everything, but I still use VB for some very concrete things which result easier than in C#.
|
|
|
|
|
Agreed... I have no problems with C#. I use it all the time. I just am aggravated with the inconsistencies of the editor. It’s not the languages fault, and I didn’t intend for it to sound like that.
See my reply below to PIEBALDconsult about what I am really ticked at here…
|
|
|
|
|
Ray Cassick wrote: get the shell of the code built for you
Either by double-clicking the control in the designer or by selecting an event from the properties pane.
|
|
|
|
|
Yeah, now see... that to me is an oddity...
Just double-clicking in the control provides you with a default event handler (in all honesty just like the VB editor does the same thing) but to get a handler for a different event you need to then go over to where the properties window is, select the button to display the events available, find the event type you want in the list and click it to see it.
Yes, I agree that you CAN ALSO do the same thing in a VB project.
I am just aggravated that for a company that tries to preach visual and usability consistency in their documentation, they go and do this. They made the UI for a C# code editor window and a VB code editor window behave in different ways.
WHY?
Trust me, I am in no way slamming C#. I LIKE the language. It’s fine for when I use it, and it gets the job done. YES, my first choice is to use VB if I can, JUST because I am used to it over the years, but I can play in both areas just fine code/concept wise.
It just aggravates me that in this day and age MS is still not following their design philosophies.
Surprised? No.
Aggravated? Yes.
Something as basic as the organization of a code editor window, in my opinion, should be a standard that the developers HAVE to follow. It would be stupid to expect a VB developer to use Ctrl+C for the copy command and then expect the C# developer to use a different command right? In fact it is against every tenant that MS establishes, but they STILL allow this kind of junk to happen within their own development teams.
Maybe the C# devs feel the ‘VB way’ of doing it is stupid or childish, or inefficient, or whatever, but the simple fact is that MS obviously little control over what their devs implement and this shows it. Here we are, VS2010 and we still see creepy differences like this.
I wonder if Eclipse or SharpDevelop have inconsistencies like this?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
