dem Formsdesigner abgeleitete Controls schmackhaft machen
-
Hallo,
gibt's eine Möglichkeit, abgeleitete Controls mit dem Windows Forms Designer
zu verwendent?z. B.
public ref class myProgressBar : public System::Windows::Forms::ProgressBar { ... };
Mein Vorgehen war:
erst einen normalen Fortschrittsbalken mit dem Formsdesigner platzieren,
dann die ZeilenSystem::Windows::Forms::ProgressBar ^ progressBar1; progressBar1 = gcnew System::Windows::Forms::ProgressBar();
ersetzen durch
myProgressBar ^ progressBar1; progressBar1 = gcnew myProgressBar();
Alles funktioniert wunderbar (compilieren, linken, ausführen),
nur im "view design" gibt's eine dicke Fehlermeldung:Could not find type 'myProgressBar'. Please make sure that the assembly that contains this type is referenced. If this type is a part of your development project, make sure that the project has been successfully built.
Lässt sich das irgendwie abstellen?
thx
Martin
-
Du solltest den vollständigen namespace für die Klasse angeben. Also z.B. "MCPP_WindowsForms1_project::MyControl1".
Auch brauchst Du es gar nicht so umständlich zu machen, sondern wenn der Designer offen ist, dann sollte in der Toolbar (also i.d.R. links) ganz oben ein Eintrag mit Deinem Projektnamen auftauchen und darin könntest Du dann deine Controls auswählen...
-
Hab jetz den vollständigen Namen angegeben (::myProgressBar)
Diesmal lautet der Fehler wie folgt:
C++ CodeDOM parser error: Line: 207, Column: 41 --- Type expected
Die betreffende Zeile:
this->progressBar1 = (gcnew ::myProgressBar());
In welcher Toolbar sollten die Controls auftauchen?
Bei aktiviertem Designer werden die Toolbars 'Standard' und 'Layout' angezeigt.
Aber ein Projekt steht nicht dabei.
Hab noch ein paar andere Toolbars angeschaut, die dem Namen nach evtl. die
richtigen sein könnten aber auch FehlanzeigeDann bleibt mir wohl nix anderes übrig, als dass ich die Controls per Hand
rein schreib...Martin
-
anonymus schrieb:
Hab jetz den vollständigen Namen angegeben (::myProgressBar)
Das ist sicher nicht der vollständige Namen. (Benutzbare) .NET-Klassen müssen immer in einem "namespace" liegen!
-
hm, hab jetzt mal ein sauberes neues Projekt angefangen und da funktioniert
das Control im Designer...So ein Müll.
Jedenfalls danke.
-
Jochen Kalmbach schrieb:
Du solltest den vollständigen namespace für die Klasse angeben. Also z.B. "MCPP_WindowsForms1_project::MyControl1".
Auch brauchst Du es gar nicht so umständlich zu machen, sondern wenn der Designer offen ist, dann sollte in der Toolbar (also i.d.R. links) ganz oben ein Eintrag mit Deinem Projektnamen auftauchen und darin könntest Du dann deine Controls auswählen...
Das wuerde ich gern ein bisschen genauer wissen. Wie und wann taucht es da auf.
Bei mir hat das damls mit .net 1.1 nur teilweise geklappt.
Jetzt hab ich das noch nie geschafft. Kann man den Code designer die selbterstellten usercontrolls irgendwie schmackhaft machen? Oder sollte er die selber erkennen sobald ich die .h file includiere wo das deffiniert ist, oder wie sollte das gehen?Danke
Flow
-
Also, wenn ich unter "Add class.." machen und dann dort das "UserControl" auswähle. Dann taucht es bei einem Form von mir in der Toolbar genz links oben auf...
-
Das Control taucht zwar immer noch in keiner Toolbar auf,
aber dafür hab ich jetzt durch Zufall was rausgefunden:Wenn man ein abgeleitetes Control (z. B. von Panel) in einem Form einbindet,
dann aktzeptiert das der Designer, solange man unter
Projekt->Properties->Configuration Properties->General
bei Common Language Runtime support die Einstellung
Pure MSIL Common Language Runtime Support (/clr:pure)
verwendet.
Stellt man um auf Common Language Runtime Support (/clr),
dann gibt's im Designer fett Stress...Solang das nur in der Express Version ist, wär naja nicht in Ordnung
aber zumindest akzeptabel, da kostenlos.Aber ich befürchte, dass es in der Professional Version genauso ist...
Zumindest kommt da der gleiche Fehler.
Werd ich am Montag gleich mal ausprobieren...
-
anonymus schrieb:
Das Control taucht zwar immer noch in keiner Toolbar auf,
aber dafür hab ich jetzt durch Zufall was rausgefunden:Wenn man ein abgeleitetes Control (z. B. von Panel) in einem Form einbindet,
dann aktzeptiert das der Designer, solange man unter
Projekt->Properties->Configuration Properties->General
bei Common Language Runtime support die Einstellung
Pure MSIL Common Language Runtime Support (/clr:pure)
verwendet.
Stellt man um auf Common Language Runtime Support (/clr),
dann gibt's im Designer fett Stress...Solang das nur in der Express Version ist, wär naja nicht in Ordnung
aber zumindest akzeptabel, da kostenlos.Aber ich befürchte, dass es in der Professional Version genauso ist...
Zumindest kommt da der gleiche Fehler.
Werd ich am Montag gleich mal ausprobieren...nun das kann ich nicht nachvollziehen, ich arbeite oft mir /clr und nicht mit pure, nutze aber immer usercontrols, ohne probleme.
@jochen: Danke, ich sollte mir mal angewoehnen so klassen bei .NET zu erstellen und nicht immer nur .h file erstellen, so wie ich das macht.
-
- Windows Forms Projekt erstellen (Name z. B. myProject)
- Der "Solution" ein neues Projekt hinzufügen: Windows Forms Dynamic Library (oder Form Control Library oder so ähnllich, nennen wir es myControls)
- Im Projekt myProject eine Referenz auf myControls setzten:
Im Solutionexplorer Rechtsklick auf den Projektnamen -> References -> Add new Reference -> Projects. Dorten das Projekt myControls wählen. - Projekt erstellen
- Rechtsklick auf die Toolbox -> Choose Items -> Browse und jetzt die *.dll suchen, die aus dem Projekt myControls entstanden ist.
Dann tauchen alle Controls aus myControls in der Toolbox auf.
-
Das Problem kommt vor wenn im Quellcode vom Komponent den namespace Name gleich wie die Klasse ist.
Beispiel:namespace EventLogViewer { public ref class EventLogViewer : public System::Windows::Forms::UserControl { public: EventLogViewer(void) { InitializeComponent(); // //TODO: Add the constructor code here //
Beim compilieren gibt's kein Fehler (es ist auch keine) aber den Visual Studio Form-Designer gibt die Fehler: "C++ CodeDOM parser error: ... - Type expected".
Eine Lösung ist den namespace Name umbennen. z. B.:
Das Problem kommt vor wenn im Quellcode vom Komponent den namespace Name gleich wie die Klasse ist.
Beispiel:namespace EventLogViewerCompo { public ref class EventLogViewer : public System::Windows::Forms::UserControl { public: EventLogViewer(void) { InitializeComponent(); // //TODO: Add the constructor code here //
hrp.