|
|
In my opinion, setting the Path of the FileSystemWatcher to an empty string is wrong.
The control is meant for watching a physical folder, so you shold provide it with a path.
If you want to stop watching the current path, you ought to set:
fw2.EnableRaisingEvents = false;
and then reenable it again the next time you provide a valid path.
Good Luck
BTW: Don't cross post! See my other answer in QA...
modified on Thursday, May 20, 2010 4:47 AM
|
|
|
|
|
|
Interesting, in the big whole, you agree with me, and you accept the fact that you cannot clear the path. So why do you vote 1 for my answer which is in fact correct? Don't shoot the messenger...
|
|
|
|
|
|
But that still doesn't warrant a vote of 1 for my reply which is correct.
It's not my fault that MS has done it that way.
As I mentioned: Don't shoot the messenger just because you don't like the message.
|
|
|
|
|
|
EthicsGradient wrote: I don't see any other option.
Don't mark it as any.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I am handling WM_PAINT message for my (winforms) TextBox. As OnPaint is not available for this control, I catch wm_paint messages. Strange this is after I hook paint event, if I add any unicode characters, textbox shows only question marks.
The control by default can handle unicode characters(without wm_paint). After I call wm_paint event, the text box is no longer accepting unicode characters. Any idea ?
|
|
|
|
|
Found the answer!
I am using non-unicode versions of API for pinvoke. When I changed to unicode versions (W-suffix) it solved all. 
|
|
|
|
|
I'm writing a simple flow calculator using <a href="http://www.brighthub.com/engineering/civil/articles/52905.aspx">Manning's Equation</a>[<a href="http://www.brighthub.com/engineering/civil/articles/52905.aspx" target="_blank" title="New Window">^</a>] to determine gravity flow rates in sewer lines. Not for publication, mind you - I'm just tired of having to do it manually with a calculator 50 times a day.
I started a new Windows Form application, added a couple of radio buttons for the user (me) to select the shape of the channel - round, rectangular, or trapezoidal - and created some functions to change the display of the main form according to which shape the user selects. The first two take two parameters, the third, three. It all works perfectly so far, to wit:
<pre> public partial class FlowCalcs : Form
{
private int Shape; //Channel shape
private int Material; //Channel material
private double N; //Manning's coefficient
private double Area; //Area of flow
private double Perimeter; //Wetted perimeter
private double Radius; //Hydraulic radius
private double Slope; //Slope of channel
private double Flow; //Flow velocity, ft/sec
private double Gpm; //Flow volume, gallons per minute
public FlowCalcs()
{
InitializeComponent();
}
private void rbtnRect_CheckedChanged(object sender, EventArgs e)
{
if (rbtnRect.Checked == true)
{
Shape = 2;
lblDh.Text = "Height, h =";
lbldW1.Text = "Width, W =";
lblW2.Visible = false;
txtW2.Visible = false;
txtW2.Enabled = false;
}
}
private void rbtnTrap_CheckedChanged(object sender, EventArgs e)
{
if (rbtnTrap.Checked == true)
{
Shape = 3;
lblDh.Text = "Height, h =";
lbldW1.Text = "Width, W1 =";
lblW2.Text = "Width, W2 =";
lblW2.Visible = true;
lblW2.Enabled = true;
txtW2.Visible = true;
txtW2.Enabled = true;
}
}
private void rbtnRound_CheckedChanged(object sender, EventArgs e)
{
if (rbtnRound.Checked == true)
{
Shape = 1;
lblDh.Text = "Diameter, D =";
lbldW1.Text = "Depth, d =";
lblW2.Text = "";
lblW2.Visible = false;
txtW2.Visible = false;
txtW2.Enabled = false;
}
}</pre>
Then the fun begins. I added a few textboxes to enter the dimensions of the channel, and coded a couple of handlers for the _TextChanged event.
<pre>private void txtDh_TextChanged(object Sender, EventArgs e)
{
testDimensions(Sender,e);
}
private void txtdW1_TextChanged(object Sender, EventArgs e)
{
testDimensions(Sender, e);
}
private void txtW2_TextChanged(object Sender, EventArgs e)
{
testDimensions(Sender, e);
}</pre>
The testDimensions method just checks the length of the text in each textbox to see if a meaningful calculation can be performed yet - a missing entry blocks execution of the numerical calculations. If all the right boxes have numbers in them it converts them to double and does the math.
The goofy bit is that, while the operations on the radio button events work perfectly, typing values into the textboxes never triggers the TextChanged event. Even weirder (is that a word?), when I use the Watch window in the debugger, every variable contained in the main Form is reported as 'does not exist in the current context' or some such wording. Another weirdity (I know that's not a word) is that, when trying to step through the program, each key click advances correctly through the Program.cs file, then it shifts to the Designer file to initialize the Form object. When that's done, my form is displayed, then it moves the cursor back to the Program.cs file, instead of the Form's main page. I haven't seen that happen before, and it confuses me greatly.
Another clue to this mystery: When I enter a value into a textbox while debugging, it makes a 'bonk' sound; when I tab to the next textbox, it doesn't. I don't know what that means, and searching MSDN for 'bonk sound' hasn't been too revealing.
By the way, there are no syntax errors, compilation errors, or runtime errors reported. According to Visual Studio 2008, my program is perfect; it just doesn't do anything. I've been beating this deceased equine for four evenings so far, with no progress. Can someone provide me a clue?
[EDIT]
Now this is odd. I posted this using Opera, and I'm now viewing it with IE7. What got posted was not what I intended viewers to see. The sig line was included in the body of the post, and the code blocks were not encoded correctly. Interesting...
[/EDIT]
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Hi Roger,
what strikes me is your TextChanged handlers use Sender, not sender. That is immaterial to the correct operation, but it tells me something has happened there.
Hint1 (experiment): change txtDh_TextChanged to txtDh_TextChanged123 (that is a one-line change!) and make sure it does not compile. If it does, it proves your txtDh is NOT wired to that handler.
Hint2: search your project for "txtDh_TextChanged_" (NOT whole word); if you find any, look for all of them. I expect there to be two, one of them containing a throw.
Hint3: maybe the textbox names are a bit odd too; I see Dh, dW1 and W2. C# is case-sensitive.
Hint4: maybe you have more than 3 textboxes, some of them at the same location, and when you think you type in one, you actually type in another one that is not wired up to a TextChanged handler.
Hint5: show us (the beginning lines of) testDimensions, and offer convincing proof it is not being called.
That is it for now. I'll be back tomorrow.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Thanks, Luc! I'll check those suggestions after work tonight. By the way, the textbox names are correct, and meant to help me keep them straight, as they are the names of the variables in the equation that are to be entered in each (D= diameter, d = depth, W1 = width1, W2 = width2). The Sender/sender thing is just my fat fingers habitually hitting the caps key; I changed them just now with no effect.
I'll try the rest later.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: The Sender/sender thing is just my fat fingers habitually hitting the caps key
No problem, except you never should feel a need to type those lines at all; either you wire the event trough the properties of the Control (the lightning tab lists the events), or you type myControl.someEvent+= and Intellisense takes over; hitting TAB twice generates the outline of the event handler for you. Doing neither of those increases the possibility something wasn't done right.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Hmmm. You lost me there. What's a 'lightning tab'? Since there's no such thing as a manual anymore, I have only a vague idea of what the IDE will do.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
inside Visual Studio, open up visual designer for the form/user control you're interested in.
select the entire form/UC or one of its Controls.
right-click it for properties (or use some menu or toolbar item); this opens the property pane.
in the property pane, you get to see 5 buttons (Categorized, Alphabetical, Properties, Events, Property Pages); they all have icons, the "Events" icon is a yellow lightning strike. That is the magical one. Click it!
Now in the list, search the event you want, and click the right cell to choose amongst the existing handlers, or double-click to create a new one.
works on all versions I can remember.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I checked it out, and it's still there; a pity I never found it before. 
Our friend dybs had the right answer, though. The Designer didn't contain a link to the handler, and a quick edit fixed that. All of the above is now working perfectly, except for the annoying "bonk" sound when I press Enter instead of Tab to move to the next field. Perhaps that's a quirk of the Debug mode and won't show up in the release version.
Now there's a new glitch, so I'll post a fresh question. Thanks for your help! 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
your "bonk" is probably an auditive signal emitted by some component you added in order to check validity and report any problems. One example would be a MaskedTextBox (you only mentioned TextBox) with its property BeepOnError set true.
If so, it will act the same in debug/release and inside/outside Visual.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Nope - I'm not yet smart enough for that. I didn't know that such a thing exists. Nothing here but labels and textboxes, all unmasked. Maybe it's hamsters farting and laughing at my terrible code?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
So I investigated your "bonk". Seems like all TextBoxes will do that by default, when present on some forms, probably all modeless forms, such as your main form.
What you are hearing most likely is a "beep" (at a high volume level). It is one of the Windows signals (a virtual sound), which by default probably causes "Ding.wav" to be played.
You could tell your PC to never do that (through the "Sound" control panel); a bad idea.
You could modify your app and have the TextBoxes swallow the unwanted characters (there probably are a lot of them, try ESC!)
The remedy is to add a KeyDown handler (and wire it up to the textbox) that decides which characters to process or not to process, something like:
private void aTextBox_KeyDown(object sender, KeyEventArgs e) {
Keys k=e.KeyCode;
if (k==Keys.Enter) {
e.Handled=true;
e.SuppressKeyPress=true;
}
}
Of course you noticed that this little filter did not refer a specific TextBox, so it could be wired up to a lot of TextBoxes.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Roger Wright wrote: dybs had the right answer
You may want and read my very first hint again, here[^].
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
I was still working on my reply by the time yours was posted.
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
|
|
|
|
|
Have you double-checked the values for txtDh, txtdW1 and txtW2 in InitializeComponent, just to make sure VS didn't do something wiered like remove/forget to add your event handlers? I've had strange things happen before where in the designer, a property shows me a certain value, but the Designer.cs file shows me something completely different (neither values being the default for the property).
Roger Wright wrote: when trying to step through the program, each key click advances correctly through the Program.cs file, then it shifts to the Designer file to initialize the Form object. When that's done, my form is displayed, then it moves the cursor back to the Program.cs file
I think this is actually normal behavior because after the form's constructor finishes, it's just the message loop running to process events. Nothing else should be happening in your form.cs file until you click one of you buttons or enter some text (at least given what you've described here). I could be wrong on the message loop thing, but this at least fits with my experience.
Dybs
The shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
|
|
|
|
|
I'll check that later tonight.
I think you're right about the behavior, but when I enter text I expect the cursor to shift back to my main Form file, and step through the lines of the code being executed. It's not doing that. Weird...
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
You nailed it - the Designer page didn't have any handlers assigned to the text boxes. A quick edit fixed that. That's my own fault. I didn't know about the Events tab in the Properties window and just typed in a handler, assuming that Visual Studio would figure it out. It didn't, and I can't blame the product for that (though the lack of a proper manual is largely to blame).
Thanks for your help, and keep an eye on this space. I'm about to post another question, hopefully the last, as I'm now at the finish line for my calculator and the last calculation is screwing me up badly with unexpected behavior.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
