I am not sure whether the following scenario is a bug in the Windows Form Designer as it relates to C++/CLI or some failing in my own implementation, but I hope someone can look at this before I submit it as a bug.

The scenario is:

I create a CLR class library project. I add a component class, let's call it CmpA. I add two virtual events to the component class, both of type System::EventHandler ^, let's call them EventA and EventI. I create backing variables for both events, let's call them bEventA and bEventI respectively, and use the long form of specifying the events. I also override the Equals and GetHashCode virtual functions.

In the same assembly I add a UserControl. The user control, let's call it UserU, has a property, let's call it PropertyU, whose type is CmpA, and a handler for CmpA's EventI. The user control also implements System::ComponentModel::ISupportInitialize, and in the EndInit() method sets up the handler for CmpA's EventI to point to its handler, if its CmpA type property has been set. The handler does nothing.

I build the project without errors, and use the Tools | Choose Toolbox Items... to add both CmpA and UserU to the toolbox.

I then create a separate Windows Form Application project, open the default form created and drop CmpA from the toolbox to the form, where it gets put in the component area on the bottom. I bring up the component's property sheet, go to the events and double-click the EventA event which is browsable. The Windows form designer sets up an event handler for the CmpA EventA in my form, and I leave the code there blank so it does nothing.

I then drop UserU from the toolbox to my form. I set User's PropertyU to the the component CmpA already on my form. I save the form, then I check that the EventA event handler for CmpA on the form and the PropertyU for the property for UserU are still set correctly. I also look at the code view of the form and see that everything is set correctly. I then close the form, and subsequently re-open it.

When I check on the property sheet for UserU, its PropertyU still points to CmpA.

However when I check on the property sheet for CmpA its EventA handler is now gone !!!

If I view the code, the code for setting CmpA's EventA handler is still there.

If I remove the override for Equals and GetHashCode in CmpA, everything works properly. If I remove the code in UserU's EndInit for setting CmpA's EventI handler to a UserU's handler function, everything works correctly. However I do not see why everything does not work correctly otherwise.

Anyone being able to test and verify this, and any comment on what is wrong with the code below would be helpful. Thank you !

The code is below.

---

The header file, CmpA.h, is:

---

#pragma once
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Diagnostics;
namespace TestDEAssembly {
public ref class CmpA : public System::ComponentModel::Component
{
public:
CmpA(void)
{
InitializeComponent();
}
CmpA(System::ComponentModel::IContainer ^container)
{
container->Add(this);
InitializeComponent();
}
virtual bool Equals(System::Object^) override;
virtual int GetHashCode() override;
virtual event System::EventHandler ^ EventA
{
void add(System::EventHandler ^);
void remove(System::EventHandler ^);
protected:
void raise(System::Object ^ sender,System::EventArgs ^ args);
}
[System::ComponentModel::Browsable(false)]
virtual event System::EventHandler ^ EventI
{
void add(System::EventHandler ^);
void remove(System::EventHandler ^);
protected:
void raise(System::Object ^ sender,System::EventArgs ^ args);
}
protected:
~CmpA()
{
if (components)
{
delete components;
}
}
private:
System::ComponentModel::Container ^components;
#pragma region Windows Form Designer generated code
void InitializeComponent(void)
{
components = gcnew System::ComponentModel::Container();
}
#pragma endregion
System::EventHandler ^ bEventA;
System::EventHandler ^ bEventI;
};
}

---

The source file, CmpA.cpp, is:

---

#include "StdAfx.h"
#include "CmpA.h"
void TestDEAssembly::CmpA::EventA::add(System::EventHandler ^ ev)
{
bEventA += ev;
}
void TestDEAssembly::CmpA::EventA::remove(System::EventHandler ^ ev)
{
bEventA -= ev;
}
void TestDEAssembly::CmpA::EventA::raise(System::Object ^ sender,System::EventArgs ^ args)
{
if (bEventA)
{
bEventA(sender,args);
}
}
void TestDEAssembly::CmpA::EventI::add(System::EventHandler ^ ev)
{
bEventI += ev;
}
void TestDEAssembly::CmpA::EventI::remove(System::EventHandler ^ ev)
{
bEventI -= ev;
}
void TestDEAssembly::CmpA::EventI::raise(System::Object ^ sender,System::EventArgs ^ args)
{
if (bEventI)
{
bEventI(sender,args);
}
}
bool TestDEAssembly::CmpA::Equals(System::Object^ obj)
{
CmpA ^ oth(dynamic_cast<CmpA ^>(obj));
if (oth)
{
if (this == oth)
{
return(true);
}
}
return(false);
}
int TestDEAssembly::CmpA::GetHashCode()
{
int ret(0);
if (bEventA)
{
ret ^= bEventA -> GetHashCode();
}
if (bEventI)
{
ret ^= bEventI -> GetHashCode();
}
return(ret);
}

---

The header file UserU.h is:

---

#pragma once
#include "CmpA.h"
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
namespace TestDEAssembly {
public ref class UserU : public System::Windows::Forms::UserControl, public System::ComponentModel::ISupportInitialize
{
public:
UserU()
{
InitializeComponent();
}
UserU(System::ComponentModel::IContainer ^ container);
virtual property TestDEAssembly::CmpA ^ PropertyU
{
TestDEAssembly::CmpA ^ get();
void set(TestDEAssembly::CmpA ^);
}
virtual void BeginInit();
virtual void EndInit();
protected:
~UserU()
{
if (components)
{
delete components;
}
}
private:
System::ComponentModel::Container ^components;
#pragma region Windows Form Designer generated code
void InitializeComponent(void)
{
this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
}
#pragma endregion
TestDEAssembly::CmpA ^ bPropertyU;
void HandleEventI(System::Object ^,System::EventArgs ^);
};
}

---

The source file UserU.cpp is:

---

#include "StdAfx.h"
#include "UserU.h"
TestDEAssembly::UserU::UserU(System::ComponentModel::IContainer ^ container)
{
container -> Add(this);
InitializeComponent();
}
TestDEAssembly::CmpA ^ TestDEAssembly::UserU::PropertyU::get()
{
return(bPropertyU);
}
void TestDEAssembly::UserU::PropertyU::set(TestDEAssembly::CmpA ^ value)
{
bPropertyU = value;
}
void TestDEAssembly::UserU::BeginInit()
{
}
void TestDEAssembly::UserU::EndInit()
{
if (bPropertyU)
{
bPropertyU -> EventI += gcnew System::EventHandler(this,&TestDEAssembly::UserU::HandleEventI);
}
}
void TestDEAssembly::UserU::HandleEventI(System::Object ^ obj,System::EventArgs ^ ev)
{
}

Its irrelevant. I won't go any further on this argument, If you care more about if your question will be solved or not, and persist in posting it in visual c++ general forum, then do it. If you want me, the person who moved it, to move it back, I am also glad to fulfill my responsibility and move it back for you. If you feel a bad experience and lack of respect that your thread being moved without notification, I am sorry but that is how forum works. It won't be possible to ask original posters every time before we are going to move it. Moreover, if we did like you suggested, then the original poster can post their question to the right place by their own when they receive a notification, then it wouldn't be a "move thread" tool exist herethat allowing usto do so.

And all above words is said with my fully respect and courtesy, if you feel not, then blame my bad english don't blame me. And I really willing you to follow up and have more discuss on the above peacefully. And all these words are based on the assumption that you care more about your question rather thatcall your bad experience even. If the assumption was wrong, then let's talk about this issure elsewhere. you will get my MSN if you really want to do so.

thanks

bite

moved from visual c++ general to windows form designer.

Please stop moving things for me. This is a C++/CLI problem, not a Windows Form Designer problem. I do not know who you are, but you need to stop taking things into your hands which you do not understand.

Because C/C++ can be used (and often is used) to program so many different technologies within MS,you can saymany technologies is more or less related to c++ (MFC, WinForm, COM, etc.), so we are very diligent about identifying off topic posts and pointing them in the right direction - the main benefit being that customers will get their questions answered better and quiker in the rightplace and the answers are then located in the correct place for others to search on and find them.

Furthermore,Do notuse "windows form designer bug" in the subject while you think it is "not a Windows Form Designer problem", that is a big misleading, pleaserefer totips on posting good questions.If you think it is a bug, you can submit it in:http://connect.microsoft.com/.

If you got problem with my work, you can take this up to the forum administrator.

thanks

Bite

Your assumption that you can just move things around to suit your own belief of where something should go rather than rely on the original poster's knowledge I find completely erroneous. You do not even bother to ask the original poster whether the post should be moved to another forum or not, showing a complete lack of respect for the original poster's knowledge, as well as a lack of courtesy. Even after I explained to you that this was a C++/CLI problem, not a Windows Form problem, you refused to believe it and instead chide me for mentioning Windows Form in my topic title even though I clearly mention C++/CLI there. Why should a problem which only occurs under C++/CLI, and which occurs in the Windows Form Designer under C++/CLI, be placed in a forum which has nothing to do with C++/CLI. Why do I even need to defend my choice of where I post a question to you.

How do I take up your high-handed attitude with a forum administrator ?

While you may well be well-intentioned in trying to place a topic in the correct forum, in this case you do not know what you are doing, and I want to not only stop future errors from you in this regard but also get my question answered by the right people, who know C++/CLI and can appraise and test out my problem.

Its irrelevant. I won't go any further on this argument, If you care more about if your question will be solved or not, and persist in posting it in visual c++ general forum, then do it. If you want me, the person who moved it, to move it back, I am also glad to fulfill my responsibility and move it back for you. If you feel a bad experience and lack of respect that your thread being moved without notification, I am sorry but that is how forum works. It won't be possible to ask original posters every time before we are going to move it. Moreover, if we did like you suggested, then the original poster can post their question to the right place by their own when they receive a notification, then it wouldn't be a "move thread" tool exist herethat allowing usto do so.

And all above words is said with my fully respect and courtesy, if you feel not, then blame my bad english don't blame me. And I really willing you to follow up and have more discuss on the above peacefully. And all these words are based on the assumption that you care more about your question rather thatcall your bad experience even. If the assumption was wrong, then let's talk about this issure elsewhere. you will get my MSN if you really want to do so.

thanks

bite

I am going to end this thread as solved and repost the message myself in a slightly different form in the C++/CLI forum. Leave my messages alone in the future and stop moving them around. I know what I am doing and all your efforts just lead to no one willing to answer my posts. Thank you !

Do you really think your threats of deleting my posts are going to keep me from speaking the truth as I see it ? All that will happen is that I will bypass using these forums and post directly to the Microsoft bug submission page or call Microsoft directly to get support.

I have tried to ask in the nicest possible way that the person who has moved my posts from the C++/CLI forum to this forum, not do so, and that if I post in a forum I actually know what I am doing and why. Why is that so hard for you and that person to accept ?

People post in forums for a reason. Why override them and think that you know better than they do ? Maybe they actually know more than you do about why they post to a particular forum.

Here is an interesting thing for you to learn in life: if you can not help people, leave them alone. You are not helping me by moving my posts around so that they have less chance of being answered in some other forum. If I am wrong about whatever forum I post a question, I will find out about it soon enough, and repost somewhere else.

I personally agree with eldiener. His problem is specific to C++/CLI and is seeking help from fellow C++/CLI users. The subset of those users who do not use Windows Forms can gloss over the question. Those who have experience with this aspect of C++/CLI can help. I greatly enjoy using C++/CLI and understand the reason for Microsoft grouping the C++/CLI and general C++ forums together, but people need to understand that by doing this you also bring in aspects of .NET and the IDE as they relate to C++/CLI.

Also, there are currently two Visual C++ sections (Not sure if they were set like this at the time of his posting)

Visual C++ General
General questions about Visual C++ 2005, including the development environment, libraries, setup, debugger, samples, and documentation.

Visual C++ Language
Issues regarding the C++ language, compiler, and linker. This forum covers all standardized languages, extensions, and interop technologies supported by Visual C++.

The Visual C++ General forum clearly states (as the first subgroup no less) that the development environment is included in the possible points of discussion.

Just my 2 cents because I'm also fustrated at the strange things which happen when using C++/CLI to design windows forms.

GrkEngineer