Class intantiation renders app unresponsive
-
OK, in the mean time I'm puzzled by the line
CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)which seems to indicate inheritance although the class declaration itself did not have any. Anyway m_FilePath is not a type, it is a member :confused::confused:Luc Pattyn [Forum Guidelines] [My Articles]
Sorry for any delays in replying, I currently don't always get e-mail notifications.
Luc Pattyn wrote:
I'm puzzled by the line CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)
Hi Luc! After the colon is the initializer list :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Well I'm almost beat....I changed the way it works like I said I would. So now the ctor does nothing but save that path until the read method is called. Yet instantiating this class still makes the application stop responding. Just as a reminder....only on client stations. On a dev station no problem. Class Declaration:
typedef cli::array< cli::array^ > TemplateArray; public ref class CFileTemplate{ //ctor and dtor public: CFileTemplate(String^ sPath); ~CFileTemplate(); //members private: String^ m_FilePath; TemplateArray^ arrCurrentTemplate; public: //methods public: //private: ->Changed for test purposes... void Process(); public: void SwitchTemplate(String^ sPath); TemplateArray^ ReturnFormat(); };The class' ctor:CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath) { MessageBox::Show("ctor"); }In the main application, here is the call:private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e) { String^ myStream; MessageBox::Show("Opening dialog"); if ( this->openFileDialog1->ShowDialog() == System::Windows::Forms::DialogResult::OK ) { MessageBox::Show("Making sure the stream is not empty"); if ( (myStream = this->openFileDialog1->FileName) != nullptr ) { MessageBox::Show("Instiating the file template object"); this->aTemplate = gcnew MFG::CFileTemplate(myStream->ToString()); //THIS IS THE CULPRIT. MessageBox::Show("instance created"); } } }Ok....to complete the explanation.....like this I never get to see the file dialog....nothing gets executed in the click event. BUT!!!!!!!!!! If I comment the line that instantiates the class.....everything goes fine. Except I cannot call the read method of course...the thing isn't instantiated.Dewm Solo - Managed C++ Developer
I'm not seeing anything here. A couple notes...
Dewm Solo wrote:
if ( (myStream = this->openFileDialog1->FileName) != nullptr )
openFileDialog1->FileName should be compared to String::Empty - the default value, not nullptr.
Dewm Solo wrote:
myStream->ToString()
Why? :) When the app goes unresponsive, if you break in the debugger, where's the current execution point at? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Luc Pattyn wrote:
I'm puzzled by the line CFileTemplate::CFileTemplate(String^ sPath) : m_FilePath(sPath)
Hi Luc! After the colon is the initializer list :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Hi Mark, thanks for reminding me. I knew once, but forgot again. Anyway the OP is in good hands now. :cool:
Luc Pattyn [Forum Guidelines] [My Articles]
Sorry for any delays in replying, I currently don't always get e-mail notifications.
-
Hi Mark, thanks for reminding me. I knew once, but forgot again. Anyway the OP is in good hands now. :cool:
Luc Pattyn [Forum Guidelines] [My Articles]
Sorry for any delays in replying, I currently don't always get e-mail notifications.
Heh. The OP was already in good hands. I just can't resist tossing my 2 cents in ;P Cheers!
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Heh. The OP was already in good hands. I just can't resist tossing my 2 cents in ;P Cheers!
Mark Salsbery Microsoft MVP - Visual C++ :java:
I'm sure, at least in C++, and probably in more areas, your 2 cents carry more weight than mine... :)
Luc Pattyn [Forum Guidelines] [My Articles]
Sorry for any delays in replying, I currently don't always get e-mail notifications.
-
I'm not seeing anything here. A couple notes...
Dewm Solo wrote:
if ( (myStream = this->openFileDialog1->FileName) != nullptr )
openFileDialog1->FileName should be compared to String::Empty - the default value, not nullptr.
Dewm Solo wrote:
myStream->ToString()
Why? :) When the app goes unresponsive, if you break in the debugger, where's the current execution point at? Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
Mark Salsbery wrote:
openFileDialog1->FileName should be compared to String::Empty - the default value, not nullptr.
Took note of that. Thanks
Mark Salsbery wrote:
Why?
....Well just to make it obvious that it really does comes out as a String...It would get optimized anyways wouldn't it?
Mark Salsbery wrote:
When the app goes unresponsive, if you break in the debugger, where's the current execution point at?
If I could have done that, believe me I would have. Like I said this issue only appears on non-development workstations. On my dev station everything works fine. No hangs or nothing. Before shipping to customers, I do like to test on regular stations that we have at work. So I tried two different machines and both did have the issue we are trying to solve now.
Dewm Solo - Managed C++ Developer
-
Mark Salsbery wrote:
openFileDialog1->FileName should be compared to String::Empty - the default value, not nullptr.
Took note of that. Thanks
Mark Salsbery wrote:
Why?
....Well just to make it obvious that it really does comes out as a String...It would get optimized anyways wouldn't it?
Mark Salsbery wrote:
When the app goes unresponsive, if you break in the debugger, where's the current execution point at?
If I could have done that, believe me I would have. Like I said this issue only appears on non-development workstations. On my dev station everything works fine. No hangs or nothing. Before shipping to customers, I do like to test on regular stations that we have at work. So I tried two different machines and both did have the issue we are trying to solve now.
Dewm Solo - Managed C++ Developer
Hi Dewm, You were getting your money's worth from Luc and Mark - here's my penny. I'll take the change with no insults... 1) Look at the generated IL. Richter does this extensively in his book CLR via C#[^]. Veryify the IL generated is what you wanted. 2) Change from initialization to assignment. I would expect if this is an issue, it is unveiled in (1). 3) WinDbg with SOS. WinDbg can debug IL. I've never had to do it, but John Robbins covers the topic extensively in Debugging Applications for Microsoft® .NET and Microsoft Windows®[^]. Jeff
-
Hi Dewm, You were getting your money's worth from Luc and Mark - here's my penny. I'll take the change with no insults... 1) Look at the generated IL. Richter does this extensively in his book CLR via C#[^]. Veryify the IL generated is what you wanted. 2) Change from initialization to assignment. I would expect if this is an issue, it is unveiled in (1). 3) WinDbg with SOS. WinDbg can debug IL. I've never had to do it, but John Robbins covers the topic extensively in Debugging Applications for Microsoft® .NET and Microsoft Windows®[^]. Jeff
Hello Jeff, 1) Looking at the IL from ildasm does look alright. 2) I changed to assignment as suggested. The ctor now only initiliaze the path string to an empty string. I added a SetFile method that takes a string from the caller and sets our path string. 3) Haven't tried the WinDbg suggestion yet. I'll look at it right after this. I wanted to put an update on here before continuing my search. BTW! The addition of the SetFile method to assign the path string gave the behavior that I was expecting. When the user clicks the 1st button the dialog now comes up and saves the path into a member of the form class. When click the 2nd button to initialize the class the application hangs. I am just instantiating the object, not even passing the path. Nothing in the constructor, which don't even take a parameter anymore. :doh: Hmmm typing this is making me realize just how weird this is. Why can't I create an instance of this object with an empty constructor???? :wtf: It's the same as if I was to type:
String^ m_Path = gcnew String();and the application would become unresponsive. That couldn't happen any more than snow in Africa. I think I'll try a little experiment. I'll add another class to the DLL of my CFileTemplate class. And see if I can instantiate that one. Just an empty object.... If anyones wants the new code or anything let me know. At this point I'm ready to post anything. I really have to get this out the door. :( Always happens this way, doesn't it? lolDewm Solo - Managed C++ Developer
-
Hi Dewm, You were getting your money's worth from Luc and Mark - here's my penny. I'll take the change with no insults... 1) Look at the generated IL. Richter does this extensively in his book CLR via C#[^]. Veryify the IL generated is what you wanted. 2) Change from initialization to assignment. I would expect if this is an issue, it is unveiled in (1). 3) WinDbg with SOS. WinDbg can debug IL. I've never had to do it, but John Robbins covers the topic extensively in Debugging Applications for Microsoft® .NET and Microsoft Windows®[^]. Jeff
Ok....I think I'm losing it guys. I added a testclass like this:
public ref class TestClass { public: TestClass(String^ jj); ~TestClass(); private: String^ sPath; };With implementation like this:TestClass::TestClass(String^ jj) { // } TestClass::~TestClass() { // }How much more simple can it get? Instantiating it like this:private: System::Void button2_Click(System::Object^ sender, System::EventArgs^ e) { MFG::TestClass^ ttt = gcnew MFG::TestClass("test"); MessageBox::Show("instance created"); }Works fine on my dev station of course, but it hangs on two other stations here that are non dev.Dewm Solo - Managed C++ Developer
-
Ok....I think I'm losing it guys. I added a testclass like this:
public ref class TestClass { public: TestClass(String^ jj); ~TestClass(); private: String^ sPath; };With implementation like this:TestClass::TestClass(String^ jj) { // } TestClass::~TestClass() { // }How much more simple can it get? Instantiating it like this:private: System::Void button2_Click(System::Object^ sender, System::EventArgs^ e) { MFG::TestClass^ ttt = gcnew MFG::TestClass("test"); MessageBox::Show("instance created"); }Works fine on my dev station of course, but it hangs on two other stations here that are non dev.Dewm Solo - Managed C++ Developer
-
Creation of such a testclass in my project of course works 100% on any workstation. So now I'm going to create a new DLL with just a test class.
Dewm Solo - Managed C++ Developer
-
Ok,....Referencing a test DLL with just a test class does the same at instantiation. The next thing I'm thinking of trying is a test app that will reference this new test dll and see what happens.
Dewm Solo - Managed C++ Developer
I creating a windows form application. I Referenced that test dll. In a button's click event created an instance of the test class. Nothing can go wrong right? I have done this at least a million times. Well ...same problem on the workstation. Does anyone has an idea? There are no other dependencies. There is nothing that can cause such a hang. ...hmmm...Just thought of something. I'm going to try to run a release build. I don't expect much out of this, but who knows what compiler optimizations might come up with. I tried this and the release builds does exactly the same. An empty app with just a button and reference to a dll that contains only a test class that has a ctor, dtor, and one string member only. It still hangs at creation of a test class object. Does anyone has suggestions? At this point I am wondering if this is not a problem that has to do with the .Net installation on the client station. Although this happens on more than one client station.... How can I debug this? On a client station nonetheless.
Dewm Solo - Managed C++ Developer
modified on Tuesday, December 18, 2007 2:53:56 PM