Auf dynamisch erzeugten NewItem reagieren

promicha

Hallo,

du kannst eine Routine für alle Einträge nutzen, diese Routine
fügst du dem OnClick ereigniss des neuen Items zu.
Inerhalb der Routine wertest du dann aus welches Item (Sender)
der Auslöser war, Stichwort "dynamic_cast".

z.B:
Nutzer Peter trägt ein: Peter

AnsiString ItemName = dynamic_cast <TMenuItem*>(Sender)->Caption;
if (ItemName == "Peter") {  //oder aus ne TStringList etc. je nach dem
   ShowMessage("Hallo Peter das ist dein Item, LOL.");
}

Am einfachsten ist es wenn du ein Item vorgiebst und auf dessen OnClick
die Routine schreibst und halt den neuen Items diese zuweisst.

gruß promicha

junix

nur, dass man das Ergebnis von Dynamic_cast zunächst noch auf NULL prüfen sollte...

-junix

promicha

nur, dass man das Ergebnis von Dynamic_cast zunächst noch auf NULL prüfen sollte...

Richtig sollte man machen, sicher ist es
Ich habe es damals am Anfang nicht gemacht, und
nie probleme erhalten mit den Progs, aber was
nicht ist kann noch werden.

Noch nen Hinweis:
Nutze TStringList mit Values und Names so kannst du dem Anweder etwas
zuweisen, wie z.B. einen Wert der für die weitere Bearbeitung innerhalb
von OnClick genutzt wird z.B.:

TStringList *Anwender = new TStringList;
Anwender->Values[ItemName] = "Eintrag"; // itemName z.B. von Edit etc.
// alle Anwender auflisten:
for (int i=0;i<Anwender->Count;i++) {
   ***Ziel*** = Anwender->Names[i];
}

Soviel als kleiner Hinweis, nun den Ablauf logisch durchdenken und
durch testen - experimentieren, und du hast das ruckzuck im griff.

gruß promicha

promicha

P.S.

die StringList global erstellen.
Also das alles nicht 1:1 übernehmen.

junix

promicha schrieb:

nur, dass man das Ergebnis von Dynamic_cast zunächst noch auf NULL prüfen sollte...

Richtig sollte man machen, sicher ist es
Ich habe es damals am Anfang nicht gemacht, und
nie probleme erhalten mit den Progs, aber was
nicht ist kann noch werden.

Jau, spätestens, wenn der böse junix kommt und deiner Methode ein anderes Objekt als ein TEdit übergibt, kreigst du hässliche Zugriffsverletzungen... Ausserdem bringt dir dynamic_cast so wie dus verwendet hast nix. Der einzige Vorteil den du durch dynamic_cast erhalten hast, hast du damit (fahrlässiger weise) egalisiert.

Für das, was du übrigens TStringList vergewaltigst, würde ich eher std::map empfehlen... ist massiv flexibler.

-junix

promicha

junix schrieb:

Ausserdem bringt dir dynamic_cast so wie dus verwendet hast nix. Der einzige Vorteil den du durch dynamic_cast erhalten hast, hast du damit (fahrlässiger weise) egalisiert.

Wie soll ich das Verstehen? Wenn ich das so in der Ereignissroutine von
ItemOnClick stehen habe kann ich auf dessen Caption gut zu greifen.

Oder meintest du:

TMenuItem *tmpItem = dynamic_cast <TMenuItem*>(Sender);
//--> beispiel für Caption
ShowMessage("klick auf: "+tmpItem->Caption);

damit ich eine komplette Instanze von dem Item habe?

Braunstein

Hallo,

Nur so kannst du ja den entstandenen Pointer auf NULL prüfen (also wenn Sender nicht vom Typ TMenuItem oder einer davon abgeleiteten Klasse ist).

Alexander Kempf

Ich frage mich ja so langsam, was eigentlich die Frage war
Ich dachte, es ginge um die Zuweisung des OnClick-Ereignisses und nicht
um die Verwendung von dynamic_cast...
Vielleicht kann ja der gut Borland-Builderman als ursprünglicher Frage-
steller sich mal dazu äußern, ob ihm die Diskussion bisher schon bei seinem
Problem geholfen hat

Gruß,

Alexander

promicha

Nur so kannst du ja den entstandenen Pointer auf NULL prüfen (also wenn Sender nicht vom Typ TMenuItem oder einer davon abgeleiteten Klasse ist).

Das ist schon klar, wenn auf NULL geprüft werden soll,
ich hatte im ersten Beispiel das auch nur gekürzt und
auf Caption zu gegriffen als Beispiel wie er da rann kommt,
vorweg sagte ich ja, Stichwort "dynamic_cast".

Aber ich denke Builderman qualmt der Kopf und der weiss immer
noch nicht wie!!

junix

promicha: Gerade für anfänger ist die gekürzte version nicht wirklich die beste. Wenn er weiss, was dynamic_cast macht und wieso man auf null prüfen soll, kann er immer noch für sich entscheiden, ob mans machen soll oder nicht... Wenn du ihm allerdings die entscheidung vorweg nimmst, lernt er eventuell einfach w as falsches.

so, nu aber schluss mit der ot-diskussion.

-junix

@promicha

schreib demnächst bei das es nur nen testschnippel ist.

@builderman

NewItem1->onClick = name_einer_routine; (zb eines buttons)

in der onclick routine (des buttons zb) benutzt du dynamic_cast so:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
        if ( TMenuItem *tmpItem = dynamic_cast <TMenuItem*>(Sender))
        {
                // menuitem gecklickt
                ShowMessage(tmpItem->Caption);
                //.......
        }
        else   // else if .... typ button .... prüfen
        {
                // button geklickt
                //.......
        }
}

@junix
du kannst auch mal helfen mit tips für den fragenden, anstatt
den helfenden zu korigieren.

Asta la H.K.

junix

Webgucker schrieb:

@junix
du kannst auch mal helfen mit tips für den fragenden, anstatt
den helfenden zu korigieren.

Wenndie helfenden fehler oder unschönheiten posten, dann ist das doch ein Tip für den fragenden, wenn ich sie korrigiere?

-junix

junix schrieb:

Wenndie helfenden fehler oder unschönheiten posten, dann ist das doch ein Tip für den fragenden, wenn ich sie korrigiere?

welcher fehler oder unschönheit? in

promicha schrieb:

AnsiString ItemName = dynamic_cast <TMenuItem*>(Sender)->Caption; 
if (ItemName == "Peter") {  //oder aus ne TStringList etc. je nach dem 
   ShowMessage("Hallo Peter das ist dein Item, LOL."); 
}

junix schrieb:

Jau, spätestens, wenn der böse junix kommt und deiner Methode ein anderes Objekt als ein TEdit übergibt, kreigst du hässliche Zugriffsverletzungen... Ausserdem bringt dir dynamic_cast so wie dus verwendet hast nix. Der einzige Vorteil den du durch dynamic_cast erhalten hast, hast du damit (fahrlässiger weise) egalisiert.

ich hoffe die anfänger sind nich beeinflust, den junix fuscht nicht
in euren code rum und ihr wisst was ihr wo für verwendet.

junix schrieb:

... als ein TEdit übergiebt,...

war der kaffee alle oder biste schon verwiert?

also Fazit:
auf NULL oder true prüfen wenn EINE routine für mehrere arten,
sonst egal, Beispiel: ich will die 5 letzten dateien anzeigen im
menu die geladen waren, diese stehen in der projektdatei, ich habe
ein menu mit datei - darunter laden speichern etc. für alle eine
OnClick routine, aus der projektdatei nehme ich die dateinamen und
füge diese als Items zu, da ich alles nach dem Caption identifiziere
brauch ich nur den caption, also reicht das was promicha schrieb aus,
auf NULL oder true prüfe ich nicht da die routine "MenuEreigniss" heist
und kein Button oder so drauf zugreift und kein junix drinn rum fuscht.
wenn der caption nicht laden, speichern oder sonst ist nehme ich diesen
als dateinamen zum laden.

im fall von Builderman der ansich anfänger ist kommt da auch
TStringList zu gute um diese kennen zu lernen und damit zu arbeiten
DENN er benutzt VCL und will mit dieser umgehen können später
kann er mal auf std::map umsteigen und C++ konform proggen.

Fazit2:
ich habe mittlerweile das gefühl das die mods hier nur klugscheißen
wollen aber nicht mal nen unterschied zu ja kann man sollte man aber,
zu ...s.c.h.e.i.ß.e... Sprüche unterscheiden können.

Asta la H.K.

junix

Zu deinem Fazit 1: Die Funktion akzeptiert TObject, also ist es durchaus gültig ein TObject zu übergebebn. Das muss allerdings nicht ein TEdit sein. Vielleicht siehst du den Fernhorizont noch nicht: Wenn man im Team entwickelt, dann kann man nicht immer den gegenüber fragen, ob er wohl die Funktion nur für Edits geschrieben hat oder Labels oder so.

Software sollte man grundsätzlich nach dem Motto "Wenn, dann richtig" entwickeln. Ebenso wichtig ist es, dass man als Anfänger einfach mal die Methoden kennenlernt, wie man sowas "richtig" macht. Avanciert man dann zum fortgeschrittenen Programmierer, so bekommt man auch langsam das Gespür dafür, wann gewisse Dinge sinn machen und wann es "sicher" ist, dass man eine Überprüfung auslässt. Dieses Gespür kann man aber nur dann entwickeln, wenn man die Mechanismen rund herum verstanden hat. Man also weiss, was Zeiger sind, was beim Ableiten einer Klasse passiert, was bei einem Cast passiert, wieso AccessVoilations entstehen können, etc. Dieses Wissen hast du als anfänger nicht (liegt wohl in der Natur der Sache, ne?). Entsprechend hat man als Anfänger auch nicht die Kompetenz zu entscheiden, ob eine Prüfung auf NULL sinn macht oder nicht. Wenn nun vorgeschlagen wird (ohne auf die Prüfung hinzuweisen), dass man so ein Konstrukt verwenden soll:

AnsiString Name_As = dynamic_cast<TLabel *>(Sender)->Caption

dann kann das zu problemen führen und der arme Anfänger muss frustriert wieder herkommen und fragen was nun wieder falsch ist.

Merke: Hilfestellungen für Anfänger sollten sich immer auf der softwaretechnisch sicheren Seite bewegen da solche Konstrukte nach der Hilfestellung bestimmt exzessiv eingesetzt werden. Ein Konstrukt wie oben ist _nicht_ auf der sicheren Seite.

Webgucker schrieb:

**Fazit2:**ich habe mittlerweile das gefühl das die mods hier nur klugscheißen wollen aber nicht mal nen unterschied zu ja kann man sollte man aber, zu ...s.c.h.e.i.ß.e... Sprüche unterscheiden können.

Wenn dir die Moderation nicht gefällt, dann beschwer dich im Neuigkeitenforum und belaste nicht technische Threads damit. Diese Scheisssprüche wie du sie nennst, sind eigentlich nichts weiter als etwas in Watte verpackte Hinweise, denen man mal selber nachgehen sollte... (->Hilfe zur Selbsthilfe) Wir haben hier eigentlich nicht das Ziel, den Anfängern alles vorzukauen, sondern ihnen in einem gewissen Masse etwas beizubringen, das sie später mal brauchen können.
Wenn dann allerdings leute wie du anfangen den versuchten Schwenk auf die sichere Seite der Softwareentwicklung mit solchen dämlichen "brauchts nicht, ihr habt nicht recht"-Posts zu torpedieren, dann beginnt das für Anfänger nur sinnlos kompliziert und verwirrend zu werden.

Schau dir mal den Post von promicha an. Er hat nach meiner Intervention sofort nachgelegt, dass man auf NULL hätte prüfen müssen und auch nochmals explizit seinen Hinweis, dass sich Buildermann über dynamic_cast noch extra schlau machen sollte, hervorgestrichen. Damit wäre die Sache geregelt gewesen. Auch deine "verbesserte" Version ist nicht unbedingt gerade für Anfänger besonders geeignet, da der Quelltext nicht wirklich auf den ersten Blick selbstdokumentierend ist. eine getrennte Zuweisung und anschliessendes prüfen auf NULL wäre auf den ersten Blick klar. Und der Optimizer des Compilers bastelt daraus sowieso wieder was ganz anderes.

Soviel dazu. Weitere off-Topic-Beiträge werden kommentarlos gelöscht. Für weitere diskussionen zum Moderationsstil oder dynamic_cast eröffnet einen neuen Thread und/oder geht direkt per Mail auf die entsprechende Person zu.

@Borland-Buildermann:
Wäre interessant, ob dein Problem nun behoben ist oder ob noch unklarheiten bestehen.

-junix

AndreasW

Webgucker schrieb:

Fazit2:
ich habe mittlerweile das gefühl das die mods hier nur klugscheißen
wollen aber nicht mal nen unterschied zu ja kann man sollte man aber,
zu ...s.c.h.e.i.ß.e... Sprüche unterscheiden können.

danke für die Verallgemeinerung. Gut zu wissen, das die User hier dankbar für die angebotene Hilfe sind. Wir werden auch ständig dafür bezahlt.