|
That code only works if an event handler was added for that method in the first place.
You could try handling Form.Closing and set a boolean field or something so that your validation event handlers don't validate if it's set. Unfortunately, I can't find any information about order of events in relation to Validating, Valiated, Closing, and Closed, but it's worth a shot. Another way - if the order is correct - would be to just remove the validating event handlers in the Closing event, so long as CancelEventArgs.Cancel (passed to the event handler) is not set to true . It might be even better that you override OnClosing and call the base.OnClosing method to make sure that all event listeners have had a chance to set CancelEventArgs.Cancel so you know for sure if you really should unhook those validation event handlers.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I've tried to remove the event handler of the control(textbox) in the closing event of the form. It didn't work.
Any way I want to be able to make the caption close button of the form not to cause the validation of the text control (in the real life there are more text controls with validating events that I don't want to fire up).
Maybe I could inherit System.Windows.Forms.Form and set some flags (like the selectable style on the button class).
Any suggestions?
Dejan
|
|
|
|
|
You can't override any functionality of the caption by inheriting from the Form class.
Did the validation events fire BEFORE or AFTER the Closing event was fired?
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Validation occures before Closing
I can't use a flag to control validation.
Dejan
|
|
|
|
|
In that case, you have to change the order. The following worked for me:- Add a boolean field called
validate (or whatever) and set it initially to true . - In your validation event handlers, simply return if
validate is false . - Override
WndProc in your form class with the following code:
protected override void WndProc(ref Message m)
{
if (m.Msg == 16)
this.validate = false;
base.WndProc(ref m);
} Your code will set the validate field before your validation handlers are called then. You could also unhook them, but this approach is a lot easier and results in fewer instructions depending on how many validation event handlers you have (and remember that similar validation handlers can be shared by many controls since the first parameter (usually called sender ) is the control that raised the event).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
It worked!!!
THNX Heath
Dejan
|
|
|
|
|
Hi all,
I've an old legacy C++ DLL that we need to access in a C# class library. I am accessing the specific functions i need using the [DllImport] method. This all works, numbers go in and out fine.
The problem? I want to step into the legacy functions when i am debugging, but the IDE (2003 .NET) just steps over the function.
How do i get access to inside the C++ DLL when debugging? am i missing something?
Thanks in advance.
|
|
|
|
|
When you attach the debugger to your application, you must specify that both CLR-managed and native application code is being debugged. Since you can't seem to configure this before debugging, you can't start your project in debug mode. Instead, start the application on your machine (the machine that built the binary to which you have source so that the PDB files are synchronized) then click Debug->Process..., find the process and double-click to debug. A dialog should come up with several debugging options. Select the types of code that is being debugged.
Now, I'm not sure if the debugger will step into externally defined functions (via the DllImportAttribute ) but I would hope it would and it's worth a shot. If nothing else, try putting a break point in the implementation code for the extern'd method. Since you should be debugging the right types of code, hopefully VS.NET will pick up on this.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Great! I didn't notice you could specify the debugging languages that are enabled. (as described in the 1st part of your comment)
I just set that up and it works right how i need it.
Thanks for the advice
|
|
|
|
|
Currently I do the following (Note that MyControl is a very basic control that has a button and a text box on it, and TargetPanel is a plain old panel that is to recieve the control).
...
...
...
protected MyControl ctrl = null;
...
...
...
ctrl = new MyControl();
TargetPanel.Controls.Add(ctrl);
...
...
...
if (TargetPanel.Controls.Contains(ctrl))
{
TargetPanel.Controls.Remove(ctrl);
}
The problem with the above implementation is that the instant I perform the Remove(ctrl), the program stops responding to WM_QUIT. everything else works perfectly, it doesnt lock up... But for some reason, it no longer responds to alt-f4, clicking the [X], pressing menu->quit, nothing. No exceptions are thrown. No debug text is printed. Does anyone have an idea on this?
|
|
|
|
|
Amusingly, after doing this a few more times, VS.NET crashed with a mysterious box that said nothing but
CATASTROPHIC FALIURE
[ok]
and wouldnt start again. (Reinstalling...)
it hates me it hates me it hates me...
|
|
|
|
|
We've already been through this - you're screwing up the application's message pump. One common way is when controls are added to another control in a separate thread. You never did respond to me if you were doing that.
All controls MUST be added and - in most cases - modified (such as adding ListViewItem s to a ListView ) in the main UI thread (the thread that started the application). This is documented in the .NET framework. If you need to add a control in a separate thread, you have to do so by invoking the control method. See Control.InvokeRequired and Control.Invoke for more information.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Ah, I thought it might be related.
Okay well, I'm not using any extra threads or anything.
Here's the sequence of events
1) User clicks on an item on a tree view, on one side of a splitter
2) Program responds to the tree selection event by creating a rich view and putting it in the right side of the splitter (by adding it to a panel's Controls.
3) User types stuff in that rich view, then selects a differerent tree node from the left view.
4) Program responds to the tree selection event by calling Panel.Remove on the rich view, and adding a different (new) one.
After step number 4, the program is no longer responding to quit commands. Could it be possible that Tree Events happen in another thread? It doesnt seem possible.
|
|
|
|
|
I did manage to 'avoid' the problem by never calling remove on the panel, but instead calling Dispose on the rich view WITHOUT removing it from the panel. (Perhaps it removes itself).
Calling Remove without ever calling dispose still causes the problem.
However, that seems messy.
It only seems to happen if the rich view has focus when it is removed. I've currently made it so that when the tree gets a 'left mouse down' event, it immediately forces focus away from the rich view BEFORE it removes it (in response to the 'tree item changed' message, which comes after the mouse down event), and that works fine... it just seems an evil hacky way to do it.
Perhaps theres some rule about not calling Remove on a control which has focus.
|
|
|
|
|
Probably is some rule about that. Keep in mind, too, that pretty much everything in System.Windows.Forms is a wrapper for the respective common control, so everything still comes down to messages (sorry if I said that before). Messages can be finicky little stinkers at times. I've also noticed that some things aren't always wrapped the best, IMHO. If you care to poke around in the PSDK, you might find more information about destroying controls that have captured the focus.
Disposing is definitely a good idea anyway. It helps free up memory quicker.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Hi,
Just wondering if someone could point me in the right direciton. What I am looking to achieve is to be able to dynamically load a class from an assembly at runtime, to achieve what use to be done using a ProgID/GUID to access a COM object. If someonce could give me a quick overview of the techniques that I should be looking at, that would be great.
Cheers
AJ
|
|
|
|
|
Check out the Activator class. I use Activator.CreateInstanceFrom in some of my code. It seems to work really well.
TF
Tim Friesen
tntfriesen1@hotmail.com
|
|
|
|
|
Extending on what Tim said, the Type is unique to each class, enum, delegate, or struct in an assembly. It contains the namespace and class name, the assembly which contains the type, and a few other pieces of information (including version, culture, and public key token (if signed - which it should be for better applications and versioning control)). This takes the place of GUIDs and ProgIDs.
Besides Activator.CreateInstance , you can have more control over type loading by using the static method Type.GetType . For instance, say in your application's .config file (yourapp.exe.config, which takes the place of the registry which you're not supposed to use in .NET unless necessary) you have a partial type string like "MyNamespace.MyType, MyFirstAssembly" (version information and other stuff can be left out as long as the CLR can resolve "MyFirstAssembly"). If you want to get the type before instantiating it, you can read the value out of the configuration file and call Type.GetType("MyNamespace.MyType, MyFirstAssembly") . That returns a Type which you can use to create an instance of use Reflection to get other information (such as whether or not it implements a particular plug-in interface you require before instantiating, although you could get this by using the is keyword after instantiating, but perhaps instantiating it is pointless to you if it doesn't implement a particular interface).
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Hi
My VS.NET installation is really annoying me. I'm using VS.NET 2003 Enterprise Developer and we have created a solution with approx. 30 projects.
VS.NET rebuilds everything every time I select to either build or run the solution - it doesn't matter if I have just changed a single line or added a new project, it always rebuilds everything.
In addition, if I choose build and then run it rebuilds everything two times - one when I choose build and one when I choose run.
Any ideas why VS.NET might be doing this? And better yet - any ideas on how to solve this issue?
Thanks for your help, Mads
|
|
|
|
|
I don't know if this is the answer to your problem but I remember having a similar problem in VS years ago.
It was due to one of the source files having the datestamp set in the future. So VS would look at the times on the source files and on the dll/exe files produced and concluded that since a source file was apparently modified after the exe/dll was produced that it must rebuild it. If that source file is in a project that all others are dependant on then everything will get rebuilt.
--Colin Mackay--
"In the confrontation between the stream and the rock, the stream always wins - not through strength but perseverance." (H. Jackson Brown)
Enumerators in .NET: See how to customise foreach loops with C#
|
|
|
|
|
This is actually the way it is supposed to work. From the main menu, the build commands work on every project in the solution. In release builds, any slight change causes the whole thing to recompile because incremental builds are disabled by default.
Here's a tip (I have about 50 projects in my solution, so I do this all the time): Right-click on the project you really want to build and select Build, Rebuild (cleans and builds), or Debug->Start new instance. This will only build the dependencies based on the file modification dates of those projects.
Another tip: To each project that has dependencies on other projects, when you click Add Reference switch to the Projects tab and select the project there. This ensures a proper dependency chain no matter which build configuration your in (Debug, Release, or a custom configuration). This also helps VS.NET resolve which dependencies should be build when you use the first tip above.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
Great tip - many thanks, not so annoyed with VS.NET anymore
Mads
|
|
|
|
|
Go to the build project, Configuration Manager option. Unmark the projects that you don't want to build.
Mauricio Ritter - Brazil
Sonorking now: 100.13560 MRitter
English is not my native language so, if you find any spelling erros in my posts, please let me know.
|
|
|
|
|
If I do that, the unmarked projects will never be included in the build (not even if they are changed).
Mads
|
|
|
|
|
I’m working as a programmer and make up my living by writing C++ apps with MFC in MS Visual Studio .NET. I have read none about C# but would like to learn it if it could make my day better.
Which are the arguments of changing language??
Pleased for all comments.
and justice for all......
- APe
|
|
|
|