|
eggie5 wrote:
Are these welcome messages necessary?
-----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-----
|
|
|
|
|
|
No, I mean I have no idea what you're talking about. What "welcome messages"?
-----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 was just trying to end the subject, because I realized I had made a typo. So, with that said. Thanks for your help.
/\ |_ E X E GG
|
|
|
|
|
Is there any way of preventing validation in windows forms when pressing the Close button (X) on the title bar
Dejan
|
|
|
|
|
Not sure about this but its worth a try.
Create an event handler for the Closing event (which gets fired just before a window is closed) and remove the validation.
--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#
|
|
|
|
|
What do you mean "remove the validation"?
I tried to do
textbox1.Validating-=<br />
new System.ComponentModel.CancelEventHandler(this.textBox1_Validating);<br />
but it doesn't work.
I have a text box with a validating event handler attached to it and when I press the close button on the title bar, it activates the validation handler for the text box. I tried to set CausesValidation to false on the form, but Can I do that on the caption's close button?
Dejan
|
|
|
|
|
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 ListViewItems 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-----
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
