C# Discussion Boards - CodeProject

Re: Close Form Validation

8-Dec-03 4:56

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) // WM_CLOSE
    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-----

mitdej8-Dec-03 20:38

mitdej

8-Dec-03 20:38

It worked!!!

THNX Heath

Dejan

Debugging C++ DLL with C#

Simon Wren8-Dec-03 0:26

Simon Wren

8-Dec-03 0:26

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.

Re: Debugging C++ DLL with C#

Heath Stewart8-Dec-03 2:54

Re: Debugging C++ DLL with C#

8-Dec-03 2:54

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.

Simon Wren8-Dec-03 3:08

Simon Wren

8-Dec-03 3:08

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 Smile | :)

What is the proper way to remove a control from a panel?

vektuz7-Dec-03 23:19

Re: What is the proper way to remove a control from a panel?

7-Dec-03 23:19

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?

vektuz8-Dec-03 0:03

Re: What is the proper way to remove a control from a panel?

8-Dec-03 0:03

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...)
Eek! | :eek:

it hates me it hates me it hates me... Eek! | :eek:

Heath Stewart8-Dec-03 2:50

Re: What is the proper way to remove a control from a panel?

8-Dec-03 2:50

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.

vektuz8-Dec-03 8:35

Re: What is the proper way to remove a control from a panel?

8-Dec-03 8:35

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.

vektuz8-Dec-03 8:48

Re: What is the proper way to remove a control from a panel?

8-Dec-03 8:48

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.

Heath Stewart8-Dec-03 9:22

Loading a class at runtime from an assembly

8-Dec-03 9:22

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.

AJ1237-Dec-03 22:53

AJ123

7-Dec-03 22:53

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

Re: Loading a class at runtime from an assembly

Tim Friesen8-Dec-03 1:29

Tim Friesen

8-Dec-03 1:29

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

Re: Loading a class at runtime from an assembly

Heath Stewart8-Dec-03 2:46

VS.NET rebuilds solution constantly?

8-Dec-03 2:46

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).

phimix7-Dec-03 22:16

phimix

7-Dec-03 22:16

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

Colin Angus Mackay8-Dec-03 1:37

Colin Angus Mackay

8-Dec-03 1:37

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#

Heath Stewart8-Dec-03 2:41

8-Dec-03 2:41

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.

phimix8-Dec-03 21:59

phimix

8-Dec-03 21:59

Great tip - many thanks, not so annoyed with VS.NET anymore Smile | :)

Mads

Mauricio Ritter8-Dec-03 4:02

Mauricio Ritter

8-Dec-03 4:02

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.

Why C# instead of C++ and MFC?

phimix8-Dec-03 4:43

phimix

8-Dec-03 4:43

If I do that, the unmarked projects will never be included in the build (not even if they are changed).

Mads

d00_ape7-Dec-03 22:08

d00_ape

7-Dec-03 22:08

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

Re: Why C# instead of C++ and MFC?

Colin Angus Mackay8-Dec-03 1:31

Colin Angus Mackay

8-Dec-03 1:31

If you are doing business applications then C# is better suited. It has easier access to databases, generating web pages, web services and so on. C++ can do these things but it takes more work.

--Colin Mackay--

Re: Why C# instead of C++ and MFC?

Heath Stewart8-Dec-03 2:37