XbpTreeView() / XbpTreeViewItem() [erledigt]

Klassen, Objekte, Methoden, Instanzen

Moderator: Moderatoren

Antworten
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von AUGE_OHR »

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 ?
Zuletzt geändert von AUGE_OHR am Mi, 09. Jan 2013 0:56, insgesamt 1-mal geändert.
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

hi,

ich versuche es mal andes : bislang nehme ich diese Syntax

Code: Alles auswählen

:addItem( <cCaption>, ; 
          [<nNormalImage> ], ; 
          [<nMarkedImage> ], ; 
          [<nExpandedImage> ], ; 
          [<cDllName>], [<xValue>] ) --> oItem | NIL 
aber es gibt ja auch diese Syntax

Code: Alles auswählen

:addItem( <oItem>, [<xValue>] ) --> oItem | NIL 
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 ?
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

hi

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 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 ?
gruss by OHR
Jimmy
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von Tom »

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
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

Tom hat geschrieben:Du willst also rausbekommen, auf welcher Ebene sich ein Item, an dem Du gerade operierst, befindet?
YUP ... wenn es prozedural wäre würde ich ProcName() verwenden ... was bei einer Class ?
Tom hat geschrieben:Ob es Child von "oTree" oder eines anderen Items ist?
ja ob es im "Root" hängt oder als SubItem
Tom hat geschrieben:Geht das nicht über o:SetParent()?
hm ... mit XbParts ...
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
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von Tom »

Vielleicht reden wir aneinander vorbei, aber:

Code: Alles auswählen

IF oItem:SetParent() == oTree
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.
Herzlich,
Tom
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

Tom hat geschrieben:Vielleicht reden wir aneinander vorbei, aber:

Code: Alles auswählen

IF oItem:SetParent() == oTree
ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.

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
wäre also meine jetzige "native" Version ( die funktioniert )
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.
ich habe ja keine Items = Objecte ...
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
UliTs
Der Entwickler von "Deep Thought"
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()

Beitrag von UliTs »

AUGE_OHR hat geschrieben:ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.
Tja, machmal hilft es auch, wenn man schreibt, was man möchte ;-) .
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

UliTs hat geschrieben:
AUGE_OHR hat geschrieben:ich habe das Problem nicht mit XbpTreeView() / XbpTreeViewItem() sondern mit meinem "native" Control wo alles in einer Class ist.
Tja, machmal hilft es auch, wenn man schreibt, was man möchte ;-) .
es ist ein BEISPIEL was ich hier mit dem "native" Control zeige was die Frage beinhaltet "wie" 2 Xbase++ Classes miteinander "kommunizieren" könnten.
PUBLIC oder PRIVATE kommen nun gar nicht in Frage und eine STATIC müsste schon n-Dim sein... hm ...
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
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()

Beitrag von UliTs »

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 8) :D .
-
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() :D
-
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 ... :-k

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

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 ;)

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)
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"...
gruss by OHR
Jimmy
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von AUGE_OHR »

hi,

so die "Parent" Zuordnung für das Object Code Demo hab ich wohl soweit.
Nodelastplus.PNG
Nodelastplus.PNG (12.43 KiB) 16214 mal betrachtet
nur die "letzten +" müsste ich noch "nachträglich" korrigieren ...
gruss by OHR
Jimmy
UliTs
Der Entwickler von "Deep Thought"
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()

Beitrag von UliTs »

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 ...
Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!
Der Handle steht natürlich zur Verfügung!
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von brandelh »

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 ...
;-)
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
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]

Beitrag von UliTs »

Hubert, wen sprichst Du an?
Meinst Du, es gibt gar kein "native" Control, auf das XbpTree.... basiert?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von brandelh »

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.
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
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]

Beitrag von UliTs »

brandelh hat geschrieben:ich meinte Jimmy und natürlich basiert XbpList
Wie kommst Du denn auf XbpList? Das kam doch in diesem Thema bisher kein einziges Mal vor.?
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von brandelh »

Tippfehler ... sollte XbpTreeView... heißen. :-)
Gruß
Hubert
UliTs
Der Entwickler von "Deep Thought"
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]

Beitrag von UliTs »

brandelh hat geschrieben:Tippfehler ... sollte XbpTreeView... heißen. :-)
Achso...
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
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem()

Beitrag von AUGE_OHR »

UliTs hat geschrieben:Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!
Der Handle steht natürlich zur Verfügung!Uli
Hubert hat ja nun versucht dir zu erklären das du auf den Holzweg ist den es geht eben NICHT um XbParts.

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
UliTs
Der Entwickler von "Deep Thought"
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()

Beitrag von UliTs »

AUGE_OHR hat geschrieben:
UliTs hat geschrieben:Ist natürlich Quatsch! Siehe mein vorheriger Beitrag!
Der Handle steht natürlich zur Verfügung!Uli
Hubert hat ja nun versucht dir zu erklären das du auf den Holzweg ist den es geht eben NICHT um XbParts.
...
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) :-k
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" ?
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.

Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9345
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 100 Mal
Danksagung erhalten: 359 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von Tom »

XbParts folgt dem Alaska Konzept mit 2 Classes obwohl man nur 1 Class bräuchte.
Dem würde ich nicht bedingungslos zustimmen. Ich halte es zuweilen für vorteilhaft, dass die Items als Einzelobjekte zur Verfügung stehen.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15689
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 65 Mal
Danksagung erhalten: 33 Mal
Kontaktdaten:

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von brandelh »

Ich halte mich da jetzt komplett raus. :badgrin:
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 :D
Gruß
Hubert
Benutzeravatar
AUGE_OHR
Marvin
Marvin
Beiträge: 12903
Registriert: Do, 16. Mär 2006 7:55
Wohnort: Hamburg
Hat sich bedankt: 19 Mal
Danksagung erhalten: 44 Mal

Re: XbpTreeView() / XbpTreeViewItem() [erledigt]

Beitrag von AUGE_OHR »

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 ?
gruss by OHR
Jimmy
Antworten