Where does it go?

Where does it go?

• kondapanaidu

  the forms designer places the code in the header file strictly for internal implementation reasons: the way the forms designer works requires that it be added there. in an ideal world you could put it wherever you wanted. you can often move the implementation of functions to a .cpp file, although in certain cases the designer may not work perfectly (or at all) if you do so. the best course of action is probably to let the designer have its way with forms you are designing and arrange your other code however you want.
  
  (I have to admit though, that this is not what I have done in the past. I used the designer to create the forms that I needed and then moved the code into the .cpp file. the designer no longer would load my form at that point, but since the bulk of the UI design had already been done, I didn't really care.)
  
  
  josh
  VC++ Project System developer
  
  

• kaffeeschluerfer

  you can place your own code wherever you want. the restriction I am referring to lies only with code that the designer generates or needs.
  
  from the information above it appears that the problem you are seeing is due to your use of namespaces. remember that anything declared in a namespace block is a member of that namespace and needs to be accessed as such. by #including your header file into the "newexternal" namespace you have added everything declared in that header into the "newexternal" namespace (i.e. newexternal::added::returnStr), but your implementation .cpp file isn't defining those members as members of the "newexternal" namespace, only of "added".
  
  solutions are to either
  a) move the #include out of the "newexternal" namespace block, or 
  b) nest everything in the "added" namespace under "newexternal" (e.g. namespace newexternal { namespace added{ /* ... */ } } )
  
  (this issue is not specific to code using the designer or to C++/CLI.)
  
  
  hope that helps,
  
  josh
  VC++ Project System developer
  
  

• Jim Thompson

  I'm sorry, I wasn't intending to say that I didn't care that the code was going into the header, or that I didn't care about your post. I was merely relating my personal experience with using this feature and how I dealt with its limitations.
  
  in fact, the VC++ team knows that this is an issue and we do care about it. unfortunately, it is a limitation of the windows forms designer for C++. much of the code can be moved out of the header without causing the designer to malfunction, but there are cases where it will cause problems.
  
  josh
  VC++ Project System developer 
  
  

• Max André Bündchen

  joshep wrote:

  (I have to admit though, that this is not what I have done in the past. I used the designer to create the forms that I needed and then moved the code into the .cpp file. the designer no longer would load my form at that point, but since the bulk of the UI design had already been done, I didn't really care.)

  
  
  Well, I care, and I'm sure that lots of others do too. Reusability is important. I don't like copying and pasting, and one of the "benifits" of C++ is reusability. I doubt very much that VC++ demands that code be put in the header (and in fact this is frowned upon by most instructors/developers). An answer is possible, and "I don't really care" isn't one.
  
  Somebody else Please tell me how to place code in a .cpp file that has scope of the form's controls.
  
  

• sparco01

  joshep wrote:

  .... much of the code can be moved out of the header without causing the designer to malfunction, but there are cases where it will cause problems.

  
  
  Well, I'm really having trouble with this. Perhaps it's because of using namespaces. I dunno.
  
  I can do this:
  
  

  namespace newexternal {

   using namespace System;
   using namespace System::ComponentModel;
   using namespace System::Collections;
   using namespace System::Windows::Forms;
   using namespace System::Data;
   using namespace System::Drawing;

   String^ returnStr(void); // my function, forward declaration
   .
   .
   .
   .
  #pragma endregion
   private: System::Void button1_Click(System::Object^  sender, System::EventArgs^  e) {
       label1->Text = returnStr();
      }
   };
   
  
  //my function
   String^ returnStr(){
       return "Added string";
   }
  
  That's about all I can manage, except for this:
  
  namespace newexternal {

   using namespace System;
   using namespace System::ComponentModel;
   using namespace System::Collections;
   using namespace System::Windows::Forms;
   using namespace System::Data;
   using namespace System::Drawing;

   #include "added.h" //my header that has forward definition
  
  
  Adding a cpp with the function definition, and removing the definition from the form1.h header, results in the function can't be found. The linker generates an error.
  
  This code, in the cpp doesn't work
  
  #include "stdafx.h"
  

  namespace added {

   using namespace System;
   using namespace System::ComponentModel;
   using namespace System::Collections;
   .
   .
   .
  
  
   String^ returnStr(void){
       return "Added string";
   }
  
  It generates an error to the effect  String^ unresolved.
  
  On top of this error, if I add to Form1.h,
  
  using namespace added;
  
  namespace 'added' is not found, even if namespace added only includes 
  
  int added_int;
  
  
  This is a serious problem! I can't live with this. Please find a solution! I have exhausted all ideas on how to solve this. I have to be able to include my own headers and cpp files. Please advise!
  
  
  
  

  
  
• Where does it go?