|
My code for calculating fluid flows in a pipe or channel is working nicely now, except for the last step. I use a textbox for user input of a selected slope, and a TextChanged event to perform the final calculation. But the moment I enter one character, my event handler is called. I thought it would wait until I tabbed away from the field, or until I pressed Enter to process the change, but apparently not. If I enter, for example, 1.234, it works fine (except that the answer is an overflow in this equation), but if I enter a decimal point, as in .016, the instant I enter the point I generate an exception - invalid format.
What am I doing wrong here? Is there another event I should use? Can I fix this one?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: Is there another event I should use?
You might want to try the Validating event.
Roger Wright wrote: Can I fix this one?
I've done this in the KeyDown event in the past, FWIW.
if (e.KeyCode == Keys.Enter)
{
double x;
if (!double.TryParse(txtBox.Text, out x))
{
MessageBox.Show(txtBox.Text + " is not a valid number");
}
}
I wouldn't do any real validating in the TextChanged event, since you can correctly type partial numbers that won't validate until you type the whole thing.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
the normal thing to do, most of the time, is to have one or more input controls that gather input parameters, but don't launch anything major; and a launch control, say a Button. So the user basically says very explicitly "I'm done, now you compute".
you can try without in simple cases, when (almost) all conceivable input values can be handled; this seldom includes the input of floating-point numbers, as you discovered.
one alternative is to use a time-out, i.e. a timer which gets reset and launched on every key stroke/mouse click into the input controls; when the timer fires, no parameter change has been applied for the last N milliseconds, so the input phase is assumed to be finished, and the compute phase is started automatically.
and then you could rely on a special key, say the ENTER key. That takes a little KeyDown handler, as you well know by now. It may be tricky to get comfortable with that solution when more than one TextBox is involved though.
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 hoping to make an interactive form, with changes to the pipe slope triggering new results without requiring an explicit button click to recalculate, but that may be beyond my present capability. The dimensions are generally static values, dictated by the design, so they don't change much. This is all new to me, being an electrical engineer pressed into service as a civil engineer, so I'm still learning a lot. I did a sensitivity analysis on the basic equation for flow and found that slope is about 10000 times more important than dimensions, so I chose slope as my primary variable for tweaking the design. I think my best solution for now is to eliminate the textbox event handler and add an Evaluate button. Later, when I get smarter about building Windows solutions, I can go back to trying to make my original design work.
Thanks for your invaluable help, Luc.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
You're welcome, Roger.
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).
|
|
|
|
|
The TextBox.Leave event is fired whenever tabbing out.
TextBox.KeyDown to check for Enter event.
private void textBox1_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == Keys.Enter)
{
MessageBox.Show("You pressed enter! Good job!");
}
}
|
|
|
|
|
Hi Roger,
Hope this doesn't arrive too late - I saw your post the other day just as I was running out the door. I don't know C# from ****, but here's pseudo-code that I've implemented in various other language/platforms. The common idea is a form with multiple text boxes, typically numeric. Modifying any one of these updates all the others affected. I'll use a real simple example: temperature conversion - boxes are celsius, fahrenheit, kelvin.
I'm assuming an event-driven environment with an accessible exception-handling mechanism, although the code can be mangled to fit dumber boxes.
float deg_cel, deg_fahr, deg_kel;
const CELSIUS = 1, FAHRENHEIT = 2, KELVIN = 3;
try
{
deg_cel = parse_to_float(text_of_cel_box);
if (deg_cel < CEL_MIN || deg_cel > CEL_MAX)
throw new exception("out of range");
update_all(CELSIUS);
}
catch (exception exc)
{
if (exc ...)
}
switch(which)
{
case CELSIUS:
deg_fahr = deg_cel * 1.80 + 32.0;
deg_kel = deg_cel + 273.16;
break;
case FAHRENHEIT:
... etc
}
if (which != CELSIUS)
text_of_cel_box = appropriate_format(deg_cel);
if (which != FAHRENHEIT)
text_of_fahr_box = appropriate_format(deg_fahr);
... etc
The biggest gotcha is if this last update of the text boxes causes another onchange event... Then you need some (dirty-ish) code to stop it infinitely recursing up its fundament.
The structure of the update routine looks a bit overkill for this simple example, but it scales nicely to things like one I did for location conversions - lat/long in different formats, zone/easting/northing on multiple grids, map sheet number/name, etc - about a dozen text boxes all up.
Cheers & HTH,
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Sorry, posted in the wrong slot in the tree, and too dumb to move it. Please see my reply to William in this thread.
P
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
I have a WinForms application I'm writing that used to work with no problems. I haven't made any changes; I haven't touched the code in a month or two due to other things in my life. Last night I went back to it to fix it up and such. When I would press Ctrl+F5 (Start Without Debugging) I got nothing. I mean, I saw the wait cursor for a couple of seconds then it disappears. I checked Task Manager and the process is there. It shows the current memory usage at ~29,000KB ... that number never changes no matter how long it sits.
If I press F5 to start debugging it works flawlessly. I have also tried in Release mode. And I have tried running the application directly from the \Debug and \Release folders outside of the VS environment. It did the same thing. Debugging is the only way it will work.
Anyone ever see this before or have suggestions? I have tried changing the target .NET version to 2.0, 3.0 and 3.5 (it was originally developed on 2.0 and worked just fine). Thanks in advance.
|
|
|
|
|
Hi,
probably some files got damaged or out of sync.
this is what I would try:
1.
close Visual, open Windows Explorer, look for your project, locate the obj folder and delete all of it; locate the bin folder, and in its debug and release subfolders, delete the files it holds that aren't files you created and are needed as inputs to your app (including the ones with ".vshost." in their name).
2.
double-click the EXE in the bin/debug folder; that may already work.
3.
open Visual, and perform a "rebuild solution".
All should be well now, unless you have messed up your project's settings.
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).
|
|
|
|
|
Well, I can now run it from the \Debug folder without running it in the debugger. However, I still can't "Start Without Debugging" in VS. I haven't changed project settings. But which one(s) could cause this?
|
|
|
|
|
I would suggest you now try a release build, and run that in the debugger, as well as by double-clicking the bin\Release\xxx.exe
If that works well, it increases the trust in the code; there are a lot of things one can do wrong, here are two relevant links:
Surviving the Release Version
http://www.codeproject.com/KB/debug/survivereleasever.aspx
Debugging Release Mode Problems
http://www.codeproject.com/KB/debug/releasemode.aspx
I have little experience with "start without debugging"; most if not all project settings seem to be common between with and without debugging. What may be quite different is the exception handling; there is an "Exceptions..." menu item under the Debug menu. Not sure what advice to give you, except what I do: always code defensively, make sure you try and catch everything that might go wrong, at some level (e.g. I always have a big try-catch in the static main that launches all), and ALWAYS do something with the exception you catch, never just swallow it.
I'm afraid I'll need some symptoms in order to be able and help you any further.
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).
|
|
|
|
|
Alright, thanks much. I'll give that a try and post back with the results. I did read somewhere to set the "Exceptions..." dialog to catch all exceptions that are thrown instead of set to "User-Unhandled". I tried that but to no avail.
Also, I tried putting a simple "MessageBox.Show("Test");" before "InitializeComponent();" in the form's constructor, MainForm.cs: MainForm(). It never even displays the MessageBox when I encounter the issue where it won't run at all.
|
|
|
|
|
Matt U. wrote: It never even displays the MessageBox
OK, that is a clear symptom of something.
If that was your main form's constructor, what is there before it, i.e. what is in your static main() method, probably inside file Program.cs? Are you doing anything special there? Loading some assemblies explicitly? running a license scheme? showing a splash screen?
Matt U. wrote: "Exceptions..." dialog to catch all exceptions
I'm always inclined to have my app catch things, that way I'm in charge, without having to worry about potential quirks in Visual Studio.
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).
|
|
|
|
|
There is nothing going on in my Program.cs aside from the default generated code.
|
|
|
|
|
Okay. Something else that may help more. When I run the application without debugging from within VS it doesn't even seem to make it into the "Main". I placed a MessageBox as the very first statement inside "static void Main()" and I never see that message. I have checked the project settings and "LME_Program" is set as the startup object for the project.
|
|
|
|
|
OK, nice. The startup object, when set, determines which class holds the static main() that should be executed when the app gets launched (both with and without debugging, as well as outside Visual).
So your startup code probably is in another file, and if it got moved on purpose, that purpose can only mean there is some special code in that static main(). You're zooming in!
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).
|
|
|
|
|
What I don't understand is the fact that I can run the application from both Debug and Release from outside of VS. I said it wasn't working before because I was simply using the "Open File" dialog in VS and right-clicking then "Open"ing the application's .exe file. If I open a Windows Explorer instance and run it from there it works just fine.
If I place the MessageBox in Program.cs and run it either in the debugger or outside of VS (where it actually runs) I see the MB no problem. For some reason "Start Without Debugging" in VS is the only problem. Do you think that for some reason the entry point is being screwed with when I run it within VS without debugging? Because that seems pretty likely, though I'm no expert.
|
|
|
|
|
well, I can't answer that unless I get some strong facts.
One would be seeing the code in the actual static main(). So locate class LME_Program and look for its main().
Another strong piece of information would be getting a better symptom than "it does not work".
My best wild guess right now is your static main is containing some special code, let's say getting some settings, or checking a license. It needs to access a file, the access is based on the "current directory" (a bad idea), and for some reason this CD is a bit volatile. I know, that is a lot of assumptions, and actually just an example.
BTW: your open dialog thingy is new to me; I never tried opening an exe using VS; and when I do, it does not launch my exe, it opens an object browser window. Anyway, don't do it. Outside VS really means double-clicking the exe in Windows Explorer.
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).
|
|
|
|
|
Yeah, I know what you mean about opening the .exe outside of VS via Explorer. That's what I was saying. I had made the mistake of opening it through the VS Open File dialog. And what I mean is that I was right-clicking the .exe in the Open File box and selecting "Open", not double-clicking to open it with VS.
Here's the code for "Program.cs" (which is set as the Startup Object in the project properties):
using System;
using System.Collections.Generic;
using System.Windows.Forms;
namespace LME
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainForm());
}
}
}
That code has been the same since the day I first created this project.
|
|
|
|
|
OK.
FYI: you replied to one of your own messages, so I didn't get an e-mail notification this time.
Things don't add up yet. So I now have several questions I would like you to answer:
1.
you mentioned startup object was set to "LME_Program", I think that is incorrect, you probably meant "LME.Program"; please confirm.
2.
I trust your MainForm class is in some other file, however also in the LME namespace?
3.
Does your program still build (and run in one mode or other) when you temporarily choose "(not set)" as the startup object?
4.
Are both classes "Program" and "MainForm" in the EXE itself, or is MainForm in a DLL (i.e. in a separate project, probably inside the same solution; and being referenced by the project that builds the EXE and gets executed)?
5.
Have you ever been putting parts of your app into the "GAC"?
6.
Is everything on (one and the same) local disk? or are network disks involved?
7.
Is there anything odd you might want to tell about, but didn't so far, as it seemed unrelated?
That's it for now.
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).
|
|
|
|
|
1.
Yes, I did mean "LME.Program" instead of "LME_Program". Sorry.
2.
Yes, it is in MainForm.cs and is also in the LME namespace.
3.
Yes, the application still runs when I choose "(Not set)" as the Startup Object.
4.
"Program" and "MainForm" are both in the same EXE.
5.
No.
6.
Yes, everything is on one (external) local disk. It's a Seagate USB drive which I've never had problems with (and don't have problems with any other projects on that drive or internal drives).
7.
There does not seem to be anything else wrong.
|
|
|
|
|
So let me summarize what we have here.
A WinForms app, in C#, has a static Main() with nothing special inside, calling a MainForm instance from within the same EXE (residing on a local disk, no DLL involved, no GAC involved), in the same namespace; the MainForm constructor starts with a MessageBox.Show() and under some circumstances this succeeds, while failing under others. The difference being only how the app is run (under Studio with debug, under Studio without debug, and straight from Explorer); removing bin and obj folders, and rebuilding, does not cure. Rebooting PC does not cure.
IMO, if all the above is accurate, the only possible conclusion is: something is ill outside your app; either your PC has problems, or your Visual Studio installation does.
[MODIFIED]
You may want to try:
- building and running your project on the same PC, but with another instance of VS (assuming you have an older or more recent one installed as well);
- building and running your project on another PC.
- building and running a very simple different project on the same PC with the same Visual.
Depending on the outcome, then maybe remove and reinstall Visual.
[/MODIFIED]
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).
|
|
|
|
|
Maybe I will attempt to re-create the project and simply copy/paste code/files. I have other projects on the same drive and they all work with no problem. One thing I did do was create backup copies of this particular project. If you recall, I had posted a while back about "List" items being deleted for some strange reason. You provided me with a list of things to do in order to improve my coding, including using "Dictionary<key,value>" objects instead of a "List".
What I did was copy the entire directory and place it in a "Backup" folder in case I needed the old code, or simply needed to go back to the old project altogether. I attempted to build/run the old copy (with the original code) and it behaves just the same. I will create an all new project tomorrow and copy/paste code/files and I will let you know what happens.
|
|
|
|
|
OK. If it is only one project out of many that misbehaves, you could start over and import the source files (but not the solution or project files). If there are multiple problematic projects, something bigger is going on. You'll figure it out.
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).
modified on Thursday, May 20, 2010 11:25 PM
|
|
|
|
|