Auf dynamisch erzeugten NewItem reagieren



  • P.S.

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



  • 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



  • 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?



  • 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).



  • 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



  • 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!!



  • 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.



  • 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.



  • 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



  • 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.

    🙄


Anmelden zum Antworten