XbpTreeView() / XbpTreeViewItem() [erledigt]
Moderator: Moderatoren
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
XbpTreeView() / XbpTreeViewItem() [erledigt]
hi,
wenn ich mir XbpTreeView() ansehe funktioniert es nicht ohne XbpTreeViewItem() -> 2 Classes
nun habe ich mein "native" Treeview in 1 x Class ... warum hat Alaska 2 Classes ?
nun frage ich mich wie komme ich zur 2nd Class da ich z.B. das HWnd ( Handle ) vom TreeView der "native" Class für die "Aktionen" in der 2nd Class benötige ?
wenn ich mir XbpTreeView() ansehe funktioniert es nicht ohne XbpTreeViewItem() -> 2 Classes
nun habe ich mein "native" Treeview in 1 x Class ... warum hat Alaska 2 Classes ?
nun frage ich mich wie komme ich zur 2nd Class da ich z.B. das HWnd ( Handle ) vom TreeView der "native" Class für die "Aktionen" in der 2nd Class benötige ?
Zuletzt geändert von AUGE_OHR am Mi, 09. Jan 2013 0:56, insgesamt 1-mal geändert.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
hi,
ich versuche es mal andes : bislang nehme ich diese Syntaxaber es gibt ja auch diese Syntax
d.h. in Xbase++ kann ich als Parameter ein Object übergeben.
ich benötige also eine 2nd Class für ein Object wobei die Ivar die Parameter enthalten.
die API Function, welche das "Handle" des "native" TreeView benötigen, sind nun alle in der 1st Class.
Frage : wie bekomme das "Handle" vom TreeView / ImageList in die 2nd Class ?
ich versuche es mal andes : bislang nehme ich diese Syntax
Code: Alles auswählen
:addItem( <cCaption>, ;
[<nNormalImage> ], ;
[<nMarkedImage> ], ;
[<nExpandedImage> ], ;
[<cDllName>], [<xValue>] ) --> oItem | NIL
Code: Alles auswählen
:addItem( <oItem>, [<xValue>] ) --> oItem | NIL
ich benötige also eine 2nd Class für ein Object wobei die Ivar die Parameter enthalten.
die API Function, welche das "Handle" des "native" TreeView benötigen, sind nun alle in der 1st Class.
Frage : wie bekomme das "Handle" vom TreeView / ImageList in die 2nd Class ?
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
hi
und hier mal ein Object CodeoItem1 und oItem2 benutzen beide die :addItem Method
oItem1 und oItem2 werden dabei als "Parent" verwendet
Frage : wie bekomme ich raus welcher "Parent" gemeint ist ?
also "ob" oItem1 oder oItem2 die :additem Method aufruft ?
und hier mal ein Object Code
Code: Alles auswählen
#include "Appevent.ch"
PROCEDURE Main
LOCAL nEvent, mp1, mp2, oXbp
LOCAL oTree, oItem1, oItem2
oTree := XbpTreeView():new( ,, {0,0}, {640,400} )
oTree:hasLines := .T.
oTree:hasButtons := .T.
oTree:create()
oItem1 := oTree:rootItem:addItem( "Erste Ebene A" )
oTree:rootItem:addItem( "Erste Ebene B" )
oItem2 := oItem1:addItem( "Zweite Ebene A" )
oItem1:addItem( "Zweite Ebene B" )
oItem2:addItem( "Dritte Ebene A" )
oItem2:addItem( "Dritte Ebene B" )
oItem2:addItem( "Dritte Ebene C" )
DO WHILE nEvent <> xbeP_Close
nEvent := AppEvent( @mp1, @mp2, @oXbp )
oXbp:handleEvent( nEvent, mp1, mp2 )
ENDDO
RETURN
oItem1 und oItem2 werden dabei als "Parent" verwendet
Frage : wie bekomme ich raus welcher "Parent" gemeint ist ?
also "ob" oItem1 oder oItem2 die :additem Method aufruft ?
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Du willst also rausbekommen, auf welcher Ebene sich ein Item, an dem Du gerade operierst, befindet? Ob es Child von "oTree" oder eines anderen Items ist? Geht das nicht über o:SetParent()?
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
YUP ... wenn es prozedural wäre würde ich ProcName() verwenden ... was bei einer Class ?Tom hat geschrieben:Du willst also rausbekommen, auf welcher Ebene sich ein Item, an dem Du gerade operierst, befindet?
ja ob es im "Root" hängt oder als SubItemTom hat geschrieben:Ob es Child von "oTree" oder eines anderen Items ist?
hm ... mit XbParts ...Tom hat geschrieben:Geht das nicht über o:SetParent()?
dann müsste ich CLASS xy FROM XbPart verwenden ... hm ...
müsste ich dann in der 2nd Class eine Object Verwaltung synchron zum TreeView haben ?
gruss by OHR
Jimmy
Jimmy
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Vielleicht reden wir aneinander vorbei, aber:
sollte eigentlich .T. liefern, wenn das Item ein Basisitem ist, bei allen anderen .F. - und die Ebenen könntest Du über die Cargo-Slots der Items ermitteln.
Ausprobiert habe ich das aber noch nicht.
Code: Alles auswählen
IF oItem:SetParent() == oTree
Ausprobiert habe ich das aber noch nicht.
Herzlich,
Tom
Tom
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.Tom hat geschrieben:Vielleicht reden wir aneinander vorbei, aber:Code: Alles auswählen
IF oItem:SetParent() == oTree
das was du da vorschlägst ist das wo ich hin will mit meinem "native" Control wobei ich ja nur Pointer und keinen "Parent" als Object habe.
Code: Alles auswählen
oTreeView := DXE_TreeView():New(oDlg,,aPos,aSize,,.F.)
//
// set before o:create if need
//
oTreeView:drawmode := XBP_DRAW_OWNER
//
oTreeView:create()
//
// after o:create()
//
oTreeView:itemSelected := {|o,st| GetItemText(o,st,oTreeView) }
nRoot := oTreeView:addItem("Parent 1", TVI_ROOT, TVI_LAST, HAVE_SUB_ITEM, 101 )
oTreeView:addItem("Parent 1 Child 1", nRoot, TVI_LAST, HAVE_ONE_ITEM, 1001)
oTreeView:addItem("Parent 1 Child 2", nRoot, TVI_LAST, HAVE_ONE_ITEM, 1002)
oTreeView:addItem("Parent 1 Child 3", nRoot, TVI_LAST, HAVE_ONE_ITEM, 1003)
nParent2 := oTreeView:addItem("Parent 2", TVI_ROOT, TVI_LAST, HAVE_SUB_ITEM, 102 )
nP2Child1 := oTreeView:addItem("Parent 2 Child 1", nParent2, TVI_LAST, HAVE_SUB_ITEM, 102)
oTreeView:addItem("Parent 2 Child 1 Child 1", nP2Child1, TVI_LAST, HAVE_ONE_ITEM, 2001)
oTreeView:addItem("Parent 2 Child 1 Child 2", nP2Child1, TVI_LAST, HAVE_ONE_ITEM, 2002)
oTreeView:addItem("Parent 2 Child 1 Child 3", nP2Child1, TVI_LAST, HAVE_ONE_ITEM, 2003)
nParent3 := oTreeView:addItem("Parent 3", TVI_ROOT, TVI_LAST, HAVE_SUB_ITEM, 103 )
nP3Child1 := oTreeView:addItem("Parent 3 Child 1", nParent3, TVI_LAST, HAVE_SUB_ITEM, 103)
nP3Child2 := oTreeView:addItem("Parent 3 Child 1 Child 1", nP3Child1, TVI_LAST, HAVE_SUB_ITEM, 103)
oTreeView:addItem("Parent 3 Child 1 Child 1", nP3Child2, TVI_LAST, HAVE_ONE_ITEM, 3001)
oTreeView:addItem("Parent 3 Child 1 Child 2", nP3Child2, TVI_LAST, HAVE_ONE_ITEM, 3002)
oTreeView:addItem("Parent 3 Child 1 Child 3", nP3Child2, TVI_LAST, HAVE_ONE_ITEM, 3003)
oTreeView:show()
RETURN
METHOD DXE_TreeView:addItem(cText,nRoot,nPos,cChildNo,nResource,cDLL)
...
nRet := ::insertItem(cText,nRoot,nPos,cChildNo,iImage)
...
// hier nun ein Object zurück geben statt eines Pointer
RETURN nRet
METHOD DXE_TreeView:insertItem(cText,nRoot,nPos,cChildNo,iImage)
LOCAL oItem := TVINSERTSTRUCT():NEW()
LOCAL nRet := 0
oItem:hParent := nRoot
oItem:hInsertAfter := nPos
oItem:item:mask := nOr(TVIF_TEXT,TVIF_CHILDREN,TVIF
oItem:item:pszText := _xgrab(cText)
oItem:item:cchTextMax := LEN(cText)+1
oItem:item:iImage := iImage
oItem:item:iSelectedImage := iImage
oItem:item:cChildren := cChildNo // Children = Sub-item
nRet := @user32:SendMessageA(::hTreeView,TVM_INSERTITEM,0,oItem)
_xfree( oItem:item:pszText )
oItem:item:cchTextMax := 0
RETURN nRet
ich habe ja keine Items = Objecte ...Tom hat geschrieben:sollte eigentlich .T. liefern, wenn das Item ein Basisitem ist, bei allen anderen .F. - und die Ebenen könntest Du über die Cargo-Slots der Items ermitteln.
die muss ich ja erst erschaffen um dem Xbase++ Conzept zu folgen was IHMO gar nicht notwendig wäre wenn man die "Reihenfolge" wie im Demo einhält.
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Tja, machmal hilft es auch, wenn man schreibt, was man möchte .AUGE_OHR hat geschrieben:ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
es ist ein BEISPIEL was ich hier mit dem "native" Control zeige was die Frage beinhaltet "wie" 2 Xbase++ Classes miteinander "kommunizieren" könnten.UliTs hat geschrieben:Tja, machmal hilft es auch, wenn man schreibt, was man möchte .AUGE_OHR hat geschrieben:ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.
PUBLIC oder PRIVATE kommen nun gar nicht in Frage und eine STATIC müsste schon n-Dim sein... hm ...
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Ich weiß zwar nicht, was Deine Antwort mit meinem -nicht ernst gemeinten- Hinweis zu tun hat, aber da wundere ich mich bei Dir nur noch in Ausnahmefällen drüber .
-
Es gibt vermutlich kein Native-Control entsprechend zu XbpTreeViewItem() .
XbpTreeViewItem() ist ja auch nicht von XbpPartHandler() abgeleitet.
-
Wenn dem so ist, warum benutzt Du dann nicht einfach XbpTreeViewItem() ?
Dann hast Du auch automatisch die Methoden XbpTreeViewItem:getChildItems() und XbpTreeViewItemgetParentItem()
-
Wenn Du trotzdem XbpTreeViewItem() neu programmieren willst, realisiere einfach ebenfalls die beiden Methoden.
-
Ich vermute, Du hast Schwierigkeiten zu sehen, wie die Parent-Child-Beziehung zustandekommt.
Das ist eigentlich ganz einfach:
Bei XbpTreeView() gibt es IMMER ein XbpTreeViewItem(), nämlich XbpTreeView:RootItem (welches unsichtbar ist). Und dieses KENNT seinen Parent und kann somit in RootItem:AddItem() auch einen Parent an neue Einträge weitergeben .
Ich hoffe, es war halbwegs verständlich ...
Uli
-
Es gibt vermutlich kein Native-Control entsprechend zu XbpTreeViewItem() .
XbpTreeViewItem() ist ja auch nicht von XbpPartHandler() abgeleitet.
-
Wenn dem so ist, warum benutzt Du dann nicht einfach XbpTreeViewItem() ?
Dann hast Du auch automatisch die Methoden XbpTreeViewItem:getChildItems() und XbpTreeViewItemgetParentItem()
-
Wenn Du trotzdem XbpTreeViewItem() neu programmieren willst, realisiere einfach ebenfalls die beiden Methoden.
-
Ich vermute, Du hast Schwierigkeiten zu sehen, wie die Parent-Child-Beziehung zustandekommt.
Das ist eigentlich ganz einfach:
Bei XbpTreeView() gibt es IMMER ein XbpTreeViewItem(), nämlich XbpTreeView:RootItem (welches unsichtbar ist). Und dieses KENNT seinen Parent und kann somit in RootItem:AddItem() auch einen Parent an neue Einträge weitergeben .
Ich hoffe, es war halbwegs verständlich ...
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
hi,
ich "denke" der erste Schritt ist getan nachdem ich die Teile welche Xbase++ betreffen in die 2nd Class geschoben haben und ein FROM DXE_TreeViewItem.
wenn ich also über DXE_TreeView:RootItem die Method ::AddItem() anfordere ist die also "geerbt" DXE_TreeViewItem
die DXE_TreeViewItem Class "weiss" aber nichts von dem DXE_TreeView "Handle" ...
eine Fieldwide STATIC würde sich ja anbieten aber ich will ja "mehrere" DXE_TreeView machen können -> n-Dim STATIC
aber wie nun der "Zugriff" wenn n-Dim Array ... und da sind wir wieder bei meiner #xTranslate Geschichte
nun habe ich also von beiden Classes, welche in einem PRG sind, den Zugriff auf ein n-Dim Array.
die beiden FUNCTION INIT / EXIT werden bei jedem DXE_TreeView ausgeführt und in aNode nehme ich nun die iVars auf und kann darin "suchen"...
ich "denke" der erste Schritt ist getan nachdem ich die Teile welche Xbase++ betreffen in die 2nd Class geschoben haben und ein FROM DXE_TreeViewItem.
wenn ich also über DXE_TreeView:RootItem die Method ::AddItem() anfordere ist die also "geerbt" DXE_TreeViewItem
die DXE_TreeViewItem Class "weiss" aber nichts von dem DXE_TreeView "Handle" ...
eine Fieldwide STATIC würde sich ja anbieten aber ich will ja "mehrere" DXE_TreeView machen können -> n-Dim STATIC
aber wie nun der "Zugriff" wenn n-Dim Array ... und da sind wir wieder bei meiner #xTranslate Geschichte
Code: Alles auswählen
#xtranslate hTreeView => a_Stack\[n_Dim, 1]
#xtranslate hImgLst => a_Stack\[n_Dim, 2]
#xtranslate aNode => a_Stack\[n_Dim, 3]
STATIC a_Stack := {}
STATIC n_Dim := 0
FUNCTION _STACKInit()
AADD( a_Stack, ARRAY( 3 ) )
n_Dim++
hTreeView := NIL
hImgLst := 0
aNode := {}
RETURN (n_Dim)
FUNCTION _STACKEXIT(nThread)
LOCAL iMax
ADEL(a_Stack,nThread)
DO WHILE .T.
iMax := LEN(a_Stack)
IF iMax = 0
EXIT
ELSEIF a_Stack[iMax] = NIL
ASIZE(a_Stack,LEN(a_Stack) - 1)
ELSE
EXIT
ENDIF
ENDDO
n_Dim := LEN(a_Stack)
RETURN (n_Dim)
die beiden FUNCTION INIT / EXIT werden bei jedem DXE_TreeView ausgeführt und in aNode nehme ich nun die iVars auf und kann darin "suchen"...
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
hi,
so die "Parent" Zuordnung für das Object Code Demo hab ich wohl soweit. nur die "letzten +" müsste ich noch "nachträglich" korrigieren ...
so die "Parent" Zuordnung für das Object Code Demo hab ich wohl soweit. nur die "letzten +" müsste ich noch "nachträglich" korrigieren ...
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!AUGE_OHR hat geschrieben:...
die DXE_TreeViewItem Class "weiss" aber nichts von dem DXE_TreeView "Handle" ...
eine Fieldwide STATIC würde sich ja
aber ich will ja "mehrere" DXE_TreeView machen können -> n-Dim STATIC
aber wie nun der "Zugriff" wenn n-Dim Array ...
Der Handle steht natürlich zur Verfügung!
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Ich frage mich die ganze Zeit, warum bei einem "native" Control plötzlich die Methoden der XbpTree.... vorhanden sein sollten
Außer du hast diese selbst implementiert ...
Außer du hast diese selbst implementiert ...
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Hubert, wen sprichst Du an?
Meinst Du, es gibt gar kein "native" Control, auf das XbpTree.... basiert?
Uli
Meinst Du, es gibt gar kein "native" Control, auf das XbpTree.... basiert?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Hallo Uli,
ich meinte Jimmy und natürlich basiert XbpList... auf einem nativen control (denke ich mal),
aber wenn Jimmy direkt auf dieses zugreift, muss er auch dort nachsehen was dieses für Methoden hat.
Die XbPart Definitionen sind dann eher unerheblich.
ich meinte Jimmy und natürlich basiert XbpList... auf einem nativen control (denke ich mal),
aber wenn Jimmy direkt auf dieses zugreift, muss er auch dort nachsehen was dieses für Methoden hat.
Die XbPart Definitionen sind dann eher unerheblich.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Wie kommst Du denn auf XbpList? Das kam doch in diesem Thema bisher kein einziges Mal vor.?brandelh hat geschrieben:ich meinte Jimmy und natürlich basiert XbpList
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Tippfehler ... sollte XbpTreeView... heißen.
Gruß
Hubert
Hubert
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Achso...brandelh hat geschrieben:Tippfehler ... sollte XbpTreeView... heißen.
Es ging darum, ob es 1 oder 2 Native-Controls gibt.
Außerdem möchte Jimmy die XbpTreeView() ersetzen. deshalb muß er auch deren Methoden nachbilden...
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem()
Hubert hat ja nun versucht dir zu erklären das du auf den Holzweg ist den es geht eben NICHT um XbParts.UliTs hat geschrieben:Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!
Der Handle steht natürlich zur Verfügung!Uli
XbParts sind selbstverständlich auch "irgendwie" auf den Windows Controls aufgebaut.
XbParts folgt dem Alaska Konzept mit 2 Classes obwohl man nur 1 Class bräuchte.
das TreeView Beispiel arbeite ja mit 2 Classes deshalb als "Beispiel"
( könnte genau so gut STATBAR, MENUBAR oder TOOLBAR nehmen... )
wenn man nun 2 Classes hat, egal was für welche, "weiss" keiner der beiden Class etwas über die "andere"
diese "Brücke" muss erst der Programmierer herstellen. Die Frage war "wie" ?
die Antwort liegt in der OOP "Vererbung" CLASS xy FROM 2ndClass.
die n-Dim Fieldwide STATIC ist nun notwendig weil man ja mehrere TreeView gleichzeitig haben könnte und diese natürlich unterschiedliche "Handle" haben.
***
ich "denke" ich habe das mit dem "+" auch kapiert was Alaska macht ... wieder mal mit Trick ...
wenn man das Object Code Demo von Alaska starte sieht man zunächst kein "+" !!!
erst wenn man mit der Maus draufgeht erscheint beim ersten Item, was Subitem hat, das "+"
es wird also im ItemSelect / ItemMark Slot erst die "+" Aktion ausgeführt
btw. sehe ich das richtig das für XbpTreeView / XbpTreeViewItem kein Ownerdraw vorgesehen ist ?
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem()
Ich rätsele schon seit einiger Zeit darüber, wo mir Hubert versucht hat zu erklären, dass ich auf dem Holzweg sei, auf welchem auch immer (Hubert klär mich auf, wenn ich Deine obigen Beiträge falsch verstanden habe)AUGE_OHR hat geschrieben:Hubert hat ja nun versucht dir zu erklären das du auf den Holzweg ist den es geht eben NICHT um XbParts.UliTs hat geschrieben:Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!
Der Handle steht natürlich zur Verfügung!Uli
...
Die Frage ist ja schon für XbpTreeView() / XbpTreeViewItem() geklärt: nämlich über die Methoden XbpTreeViewItem:getChildItems() und XbpTreeViewItem:getParentItem() . Und das sind höchstwahrscheinlich Einzeiler.AUGE_OHR hat geschrieben:wenn man nun 2 Classes hat, egal was für welche, "weiss" keiner der beiden Class etwas über die "andere"
diese "Brücke" muss erst der Programmierer herstellen. Die Frage war "wie" ?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9394
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 104 Mal
- Danksagung erhalten: 364 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Dem würde ich nicht bedingungslos zustimmen. Ich halte es zuweilen für vorteilhaft, dass die Items als Einzelobjekte zur Verfügung stehen.XbParts folgt dem Alaska Konzept mit 2 Classes obwohl man nur 1 Class bräuchte.
Herzlich,
Tom
Tom
- brandelh
- Foren-Moderator
- Beiträge: 15707
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 71 Mal
- Danksagung erhalten: 38 Mal
- Kontaktdaten:
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
Ich halte mich da jetzt komplett raus.
Beim Überfliegen des Threads hatte ich mich gewundert, dass einerseits von der Nutzung des "nativen" TreeView Controls geschreiben wurde,
andererseits immer Fragen zu XbpTreeView... eingegangen sind ... diese Verwunderung wollte ich zum Ausdruck bringen.
Keinesfalls möchte ich im Zustand der aktuellen Unklarheit eine Belehrung loswerden
Beim Überfliegen des Threads hatte ich mich gewundert, dass einerseits von der Nutzung des "nativen" TreeView Controls geschreiben wurde,
andererseits immer Fragen zu XbpTreeView... eingegangen sind ... diese Verwunderung wollte ich zum Ausdruck bringen.
Keinesfalls möchte ich im Zustand der aktuellen Unklarheit eine Belehrung loswerden
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: XbpTreeView() / XbpTreeViewItem() [erledigt]
hi,
so langsam komme ich hinter das "Geheimnis" der 2nd Class. im Grunde ist es ein Array
ob ich nun Pointer / Handle oder Object in einem Array habe ist zunächst mal egal.
nun will ich aber mit den "Daten" umgehen und dazu nehmen wir unter Xbase++ GetData() / SetData() und die kommen von DataRef()
ich könnte zwar die paar Ivars von DataRef() auch mit in ein Array aufnehmen aber da gibt es ja noch den ::Datalink ...
also muss die 2Class FROM DataRef ... sein um noch "weitere" Daten aufzunehmen die nicht ein Node oder Sub-Node sind ( sondern der "Value" im Sub-Node )
siehe http://www.xbaseforum.de/viewtopic.php? ... 943#p77943
p.s. hat jemand eine ::datalink Beispiel für ein TreeView ?
so langsam komme ich hinter das "Geheimnis" der 2nd Class. im Grunde ist es ein Array
ob ich nun Pointer / Handle oder Object in einem Array habe ist zunächst mal egal.
nun will ich aber mit den "Daten" umgehen und dazu nehmen wir unter Xbase++ GetData() / SetData() und die kommen von DataRef()
ich könnte zwar die paar Ivars von DataRef() auch mit in ein Array aufnehmen aber da gibt es ja noch den ::Datalink ...
also muss die 2Class FROM DataRef ... sein um noch "weitere" Daten aufzunehmen die nicht ein Node oder Sub-Node sind ( sondern der "Value" im Sub-Node )
siehe http://www.xbaseforum.de/viewtopic.php? ... 943#p77943
p.s. hat jemand eine ::datalink Beispiel für ein TreeView ?
gruss by OHR
Jimmy
Jimmy