Listbox in Groupbox in abgeleiteter Klasse will nicht [erledigt]

Klassen, Objekte, Methoden, Instanzen

Moderator: Moderatoren

Antworten
Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Listbox in Groupbox in abgeleiteter Klasse will nicht [erledigt]

Beitrag von Klaus Schuster » Fr, 13. Apr 2018 10:04

Hallo Leute,

hat jemand eine Idee warum

Code: Alles auswählen

CLASS ArtikelListbox FROM XbpStatic, XbpListbox

   EXPORTED

      METHOD init
      METHOD create

ENDCLASS


METHOD ArtikelListbox:init( oParent, oOwner, aPos, aSize, aPP, lVisible )

   // Parts initialisieren

   ::XbpStatic:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
   ::XbpStatic:caption      := "Artikel"
   ::XbpStatic:clipSiblings := .T.
   ::XbpStatic:type         := XBPSTATIC_TYPE_GROUPBOX

   ::XbpListbox:init( ::XbpStatic,, { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPP, lVisible )

RETURN SELF



METHOD ArtikelListbox:create

   ::XbpStatic :create()
   ::XbpListbox:create()

RETURN SELF
abstürzt, wenn ich die beiden Zeilen ::XbpListbox:init und :create entferne jedoch problemlos eine Groupbox angezeigt wird?
Zuletzt geändert von Klaus Schuster am Mo, 16. Apr 2018 14:11, insgesamt 1-mal geändert.
Gruß Klaus

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 10:39

Du erstellst die Groupbox doch

Code: Alles auswählen

::XbpStatic:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
::XbpStatic:caption      := "Artikel"
::XbpStatic:clipSiblings := .T.
::XbpStatic:type         := XBPSTATIC_TYPE_GROUPBOX
egal ob die ListBox initialisiert / created wird ... warum sollte das Static nicht angezeigt werden oder verstehe ich die Frage falsch ?
Gruß
Hubert

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Fr, 13. Apr 2018 10:57

Hallo Hubert,

ja, ja, die Static wird angezeigt. Die Listbox jedoch wird nicht nur nicht angezeigt, sondern führt zu einem sang- und klanglosen Absturz.
Gruß Klaus

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 11:06

mit welcher Fehlermeldung und wo genau im Code ?

zuerst dachte ich an ::XbpStatic, aber das hat seinen INIT schon hinter sich und im Class code steht ja auch alles in der init() und danach kommt für alle erst create
Gruß
Hubert

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Fr, 13. Apr 2018 12:12

der Abgang erfolgt ohne jede Fehlermeldung. Die Anwendung läuft noch ein paar Sekunden und wird dann ohne Meldung geschlossen. Es sieht so aus, als würden solange Ressourcen verbraucht, bis es nicht mehr geht. Der Fehler tritt erstaunlicherweise auf, wenn die ::XbpListbox:ini gelaufen ist, und das Programm ::XbpStatic:create() ausführen soll.
Gruß Klaus

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11457
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von AUGE_OHR » Fr, 13. Apr 2018 13:00

moin,
Klaus Schuster hat geschrieben:
Fr, 13. Apr 2018 10:04
hat jemand eine Idee warum
ich habe noch nie eine Class gesehen wo es 2 x oXbPart:Init gibt.

Code: Alles auswählen

 ::XbpStatic:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
 ::XbpListbox:init( ::XbpStatic,, { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPP, lVisible )
entweder mache ich eine CLASS FROM XbpStatic ODER XbpListbox aber nicht beides :shock:
überhaupt ist die Frage warum du eine solchen CLASS haben möchtest :?:

ich machen entweder mittels CLASS eine Erweiterung eines XbParts ODER eine CLASS from XbpDialog()
bei einer CLASS from XbpDialog() setzte ich die Childs, welche vorher eine Function / Procedure war,

Code: Alles auswählen

* --------- old Procedure Code ---------- *

   oDlg := XbpDialog():New(...)
   ...
   oDlg:Create()

   // hier die Childs
      ...
   oDlg:Show()
   // Event loop
   nEvent := 0
   DO WHILE !lExit
      nEvent := AppEvent( @mp1, @mp2, @oXbp )
      oXbp:handleEvent( nEvent, mp1, mp2 )
   ENDDO
RETURN
dann so als CLASS

Code: Alles auswählen

* --------- same now as CLASS Code ---------- *

   oDlg := MyClass():New(...)
   ...
   oDlg:Create()
   
   // die Childs werden in o:DoMore angelegt
   
   oDlg:Show()
   // Event loop
   nEvent := 0
   DO WHILE !lExit
      nEvent := AppEvent( @mp1, @mp2, @oXbp )
      oXbp:handleEvent( nEvent, mp1, mp2 )
   ENDDO

RETURN

* -------------------------------------------------------------- *

METHOD MyClass:INIT( oParent, oOwner, aPos, aSize, aPP, lVisible )
   ::XbpDialog:init( oParent, oOwner, aPos, aSize, aPP, lVisible )
RETURN self

METHOD MyClass:CREATE( oParent, oOwner, aPos, aSize, aPP, lVisible )
   ::XbpDialog:create( oParent, oOwner, aPos, aSize, aPP, lVisible )
   ::DoMore()
RETURN self

METHOD Kachel:DoMore() 
   // hier die Childs on o:DrawingArea

RETURN self
der Code in o:DoMore kann im Prinzip der alter Code sein mit LOCAL
nur wenn man die Controls "direkt" ansprechen will würde ich eine iVAR daraus machen
gruss by OHR
Jimmy

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 14:07

AUGE_OHR hat geschrieben:
Fr, 13. Apr 2018 13:00
moin,
ich habe noch nie eine Class gesehen wo es 2 x oXbPart:Init gibt.
entweder mache ich eine CLASS FROM XbpStatic ODER XbpListbox aber nicht beides :shock:
überhaupt ist die Frage warum du eine solchen CLASS haben möchtest :?:
ich machen entweder mittels CLASS eine Erweiterung eines XbParts ODER eine CLASS from XbpDialog()
nur wenn man die Controls "direkt" ansprechen will würde ich eine iVAR daraus machen
also von 2 Klassen erben ist nicht nur erlaubt, sondern viele XbParts tun das, meist von einem Fenster und der Daten Komponente.

Aber in dem Falle würde ich auch so vorgehen, dass ich von XbpListbox ableite und dort eine iVar mit einer GroupBox anlege.

Ich habe einmal einen eigenen Pushbutton gemacht, der eine Box um sich selbst gemalt hat (grün = alles OK, rot = da muss man sich um was kümmern),
dafür habe ich aber kein Control benutzt, wenn ich eine Listbox in der Größe beschränken wollte bzw. gruppieren,
habe ich die immer selbst im Fenster angelegt.
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 14:12

Klaus Schuster hat geschrieben:
Fr, 13. Apr 2018 12:12
der Abgang erfolgt ohne jede Fehlermeldung. Die Anwendung läuft noch ein paar Sekunden und wird dann ohne Meldung geschlossen. Es sieht so aus, als würden solange Ressourcen verbraucht, bis es nicht mehr geht. Der Fehler tritt erstaunlicherweise auf, wenn die ::XbpListbox:ini gelaufen ist, und das Programm ::XbpStatic:create() ausführen soll.
Kannst du den Quellcode in einem Miniprogramm mit pbuild.xpj zur Verfügung stellen (PN oder hier als ZIP) ?
Ich würde mir das mal ansehen, grundsätzlich ist ein "verschwindet einfach ohne Fehlermeldung" häufig eine Endlosschleife die den Stack bis zum bitteren Ende füllt und somit keine XppError.log erzeugen kann.
Normalerweise sollte es dann eine XppFatal.log geben, meist mit Inhalt Stack-overflow ... aber wenn das aktuell eingestellte Verzeichnis einen Schreibschutz hat oder aus sonstigen Gründen kommt das schon vor dass nix da ist.
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 15:59

Ich war blind, du musst natürlich das Static als Objekt erzeugen, nicht einfach nur in der Klasse selbst.
Durch das Vererben erhält man die Eigenschaften der Klassen, nutzen tut man die in einem Objekt der Klasse.

Ich sehe mal dass ich später ein funktionierendes Beispiel reinstelle mit einer Box um die Listbox
Gruß
Hubert

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Fr, 13. Apr 2018 18:42

Hallo Hubert,

Deine Einschätzung deckt sich mit der Wahrnehmung wie ich sie bereits beschrieben habe. Es wäre klasse, wenn Du mir ein paar Zeilen Quellcode zukommen lassen könntest! Falls nötig, stelle ich gerne eine Testroutine zusammen.

@Jimmy: Das eine Klasse von mehreren Superklassen abgeleitet wird, siehst Du z.B. an XbpListbox welche XbpWindow() und DataRef() als Supperklassen hat. Du schreibst jedoch "ich habe noch nie eine Class gesehen wo es 2 x oXbPart:Init gibt.". Wie sollte es aber anders gehen?! Die von Dir skizzierte Lösung hebe mir für den Notfall auf. Derzeit versuche ich noch den Ansatz, wie er im Code dargestellt wird.

Herzlichen Dank euch Beiden!
Gruß Klaus

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 18:43

Hallo,

in beiliegender ZIP findest du ein Beispiel Projekt, mit vermutlich dem gewünschten Ergebnis.
Ich habe einige #IF Abfragen drin, damit man leicht zwischen Standard und Spezial umstellen kann, die macht man natürlich raus.
Ansonsten, statt XbpListbox():new(...) einfach MyListBox():new(...) verwenden, bei gleichen Parametern. (bei mir _Main.prg )
Ich hätte die Größe der Xbp übrigens gleich gelassen und den Rahmen vergrößert, aber deine Vorgabe sah anders aus.
Aktuell habe ich das mit der 2.00.918 übersetzt, aber zumindest die MyListBox.PRG geht auch in 1.90 - da ist nichts besonderes drin.

Code: Alles auswählen

/// MyListbox.prg
#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Appevent.ch"
#include "Font.ch"

// nur für den Test, später alles unnötige entfernen
#define NUTZEORIGINALLISTBOX .f.


 CLASS myListBox FROM XbpListBox
 EXPORTED:
   VAR    oRahmen
   METHOD init, create, destroy
 ENDCLASS
 *----------------------------------------------------------------------------
 METHOD init(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
    LOCAL aPPRahmen
#if NUTZEORIGINALLISTBOX // Standard ohne Rahmen nutzen !
    SUPER:init(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
#else
    aPPRahmen := NIL
    ::oRahmen   := XbpStatic():new( oParent, oOwner, aPos, aSize, aPPRahmen, lVisible ) // wenn lVisible = .f. dann ist was bei Show nötig
    ::oRahmen:caption      := "Artikel"
    ::oRahmen:clipSiblings := .T.
    ::oRahmen:type         := XBPSTATIC_TYPE_GROUPBOX
    // Vorgabe Listbox verkleinern, warum nicht ;-)
    // ::XbpListbox:init( ::XbpStatic,, { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPP, lVisible )

    SUPER:init(::oRahmen, , { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPresParam,lVisible)
#endif
 RETURN self
 *----------------------------------------------------------------------------
 METHOD create(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
#if NUTZEORIGINALLISTBOX // Standard ohne Rahmen nutzen !
#else
    ::oRahmen:create()
#endif
    SUPER:create(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
#if NUTZEORIGINALLISTBOX // Standard ohne Rahmen nutzen !
    ::addItem( "1. Vorgabe von myListBox - original" )
    ::addItem( "2. Vorgabe von myListBox - original" )
    ::addItem( "3. Vorgabe von myListBox - original" )
#else
    ::addItem( "1. Vorgabe von myListBox - mit Rahmen" )
    ::addItem( "2. Vorgabe von myListBox - mit Rahmen" )
    ::addItem( "3. Vorgabe von myListBox - mit Rahmen" )
#endif

 RETURN self
 *----------------------------------------------------------------------------
 METHOD destroy()
    SUPER:destroy()
    ::oRahmen:destroy()
 RETURN self

gekürzt auf das Nötige:

Code: Alles auswählen

/// MyListbox.prg
#include "Gra.ch"
#include "Xbp.ch"
#include "Common.ch"
#include "Appevent.ch"
#include "Font.ch"

CLASS myListBox FROM XbpListBox
 EXPORTED:
   VAR    oRahmen
   METHOD init, create, destroy // aufräumen nicht vergessen
 ENDCLASS
 *----------------------------------------------------------------------------
 METHOD init(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
    LOCAL aPPRahmen
    aPPRahmen := NIL
    ::oRahmen   := XbpStatic():new( oParent, oOwner, aPos, aSize, aPPRahmen, lVisible ) // wenn lVisible = .f. dann ist was bei Show nötig
    ::oRahmen:caption      := "Artikel"
    ::oRahmen:clipSiblings := .T.
    ::oRahmen:type         := XBPSTATIC_TYPE_GROUPBOX
    // Vorgabe Listbox verkleinern, warum nicht ;-)
    // ::XbpListbox:init( ::XbpStatic,, { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPP, lVisible )
    SUPER:init(::oRahmen, , { 12, 12 }, { aSize[1] - 24, aSize[2] - 24 }, aPresParam,lVisible)
 RETURN self
 *----------------------------------------------------------------------------
 METHOD create(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
    // wir brauchen den zuerst, sonst kommt ein falscher Objektstatus beim compilieren
    ::oRahmen:create() 
    SUPER:create(oParent, oOwner, aPos, aSize, aPresParam,lVisible)
 RETURN self
 *----------------------------------------------------------------------------
 METHOD destroy()
    SUPER:destroy()
    ::oRahmen:destroy()
 RETURN self
Dateianhänge
MyListBox-verbessert.zip
mit destroy() muss man aufräumen
(4.7 KiB) 21-mal heruntergeladen
Gruß
Hubert

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 18:51

Grundsätzlich erbt man von allen Klassen, deren Verarbeitung oder Eigenschaften man braucht.
Wenn man nur - wie hier einen Rahmen anzeigen will, der aber keine besondere Verarbeitung machen soll (z.B. auf Klicks reagieren) brauchen wir den nicht als Basisklasse.
Wir legen einfach ein Objekt intern an und nutzen dies.

Eventuell sollte man noch ein :destroy() dran hängen um dieses Objekt auch zu killen, bin mir nicht sicher ob das der GC automatisch macht, das wäre dann so ...

Code: Alles auswählen

*----------------------------------------------------------------------------
 METHOD destroy() // in der Class Beschreibung nicht vergessen
    SUPER:destroy()
    ::oRahmen:destroy()
 RETURN self
schön ist es auch wenn man die Klasse davor schreibt, aber ok muss nicht, wenn man eine Klasse pro PRG hat.
Gruß
Hubert

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Fr, 13. Apr 2018 19:00

Hubert, herzlichen Dank für den Code und vor allem auch für die plausible Erklärung!

Es scheint, dass irgendetwas in der Vererbung dazu führt, dass in einem geerbten Objekt kein anders, ebenfalls geerbtes, Object verwandt werden kann. Ich werde den Code kommende Woche einmal an den Support senden, vielleicht könne sie erklären, was intern abläuft.

Deine Lösung funktioniert, und das ist viel wert! Ein schönes Wochenende.
Gruß Klaus

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Fr, 13. Apr 2018 19:03

Ich habe die verbesserte Version mit destroy() oben eingefügt, immer schön ans aufräumen denken ;-)
Gruß
Hubert

Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 11457
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von AUGE_OHR » Sa, 14. Apr 2018 1:26

Klaus Schuster hat geschrieben:
Fr, 13. Apr 2018 18:42
@Jimmy: Das eine Klasse von mehreren Superklassen abgeleitet wird, siehst Du z.B. an XbpListbox welche XbpWindow() und DataRef() als Supperklassen hat. Du schreibst jedoch "ich habe noch nie eine Class gesehen wo es 2 x oXbPart:Init gibt.". Wie sollte es aber anders gehen?! Die von Dir skizzierte Lösung hebe mir für den Notfall auf. Derzeit versuche ich noch den Ansatz, wie er im Code dargestellt wird.
XbpWindow() oder Dataref() sind doch abstrakte CLASSen aber keine XbPart in dem Sinn.
wenn ich 2 x XbPart hätte dann würde es sicherlich Methoden geben welche beide XbPart haben ... und dann :?:

wie ich schon sagte würde ich zuerst die CLASS o:Init() / o:Create() erstellen und dann die "anderen" XbParts mit o:New() anlegen (in o:DoMore). so bekommt man Prozeduralen Code schnell in eine CLASS.

wenn man nicht wie ich völlig neue Control für eine LIB bauen will ist es in 99% ein "Fenster" also XbpDialog()
nun hat aber nicht das Fenster besondere Eigenschaften sondern enthält ein Anzahl von XbParts was es von "anderen" Fenstern unterscheidet ( Artikel/Kunden/Faktu ...). nun würde man aber nicht

Code: Alles auswählen

CLASS ArtikelDialog FROM XbpDialog, XbpStatic, XbpListbox, Xbpblabla
schreiben sondern die XbParts als iVAR innerhalb (PROTECT) oder auch ausserhalb (EXPORTED) verwenden.
gruss by OHR
Jimmy

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Mo, 16. Apr 2018 7:52

Guten Morgen und Danke,

@Hubert: "immer schön ans aufräumen denken ;-)" - mach ich Papa :D .
@Jimmy: So ist es in jedem Fall lösbar, und von Hubert auch realisiert. Mich würde nur interessieren, warum es nicht so wie im Beispiel geht. Mal sehen, ob sich der Support dazu äußert. Interessieren deshalb, weil mir Seiteneffekte Unsicherheit bereiten.
Gruß Klaus

Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 14587
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Kontaktdaten:

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von brandelh » Mo, 16. Apr 2018 8:47

Ich denke Jimmy hat es weiter oben gut erklärt, XbParts erben teilweise von mehreren Basisklassen die Eigenschaften.
In deinem Beispiel hattest du eine Klasse erstellt und von beiden geerbt.

Code: Alles auswählen

CLASS ArtikelListbox FROM XbpStatic, XbpListbox
Ich meine, dass immer der erste Eintrag die Haupteigenschaften (Standardaussehen) liefert, also hattest du eine Groupbox geschaffen, die auch von Listbox Eigenschaften haben könnte.
Es ist immer wichtig, von der Klasse als erstes zu erben, die den gewünschten Eigenschaften am nächsten kommt.
Bei der Erzeugung eines Objektes wäre also eine GroupBox entstanden, aber eben nur ein Objekt, das wie ein Zwitter mehrere Eigenschaften hatte.
Beim Versuch die 2. Basisklasse mit einem eigenen Teil als parent zu erstellen, kommt es dann wohl zur Endlosschleife die den Absturz erzeugt.
Alles nur Vermutung, aber ich denke das dürfte passen ;-)

Du brauchst jedoch eine Listbox, die in sich eine GroupBox automatisch verwaltet, das macht man (wie ich oben gezeigt habe),
indem man ein Objekt der Standard Groupbox Klasse anlegt.
Gruß
Hubert

Benutzeravatar
Klaus Schuster
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 190
Registriert: Do, 24. Jan 2008 10:01
Wohnort: 90762 Fürth

Re: Listbox in Groupbox in abgeleiteter Klasse will nicht

Beitrag von Klaus Schuster » Mo, 16. Apr 2018 14:11

laut Support lassen sich die mit den Controls verbundenen Datenstrukturen nur eingeschränkt auf diese Art vererben. again what learned.
Gruß Klaus

Antworten