XProfan

Frank
Abbing

Hi,

habe dir hier bereits zu Ähnlichem geantwortet, du mußt auch mal darauf reagieren: [...]

Ist eine Notifymessage, die du auslesen mußt, TVN_SELCHANGED. Bei meinen Versuchen im Dialogstyle mußte ich sowohl die A (-402), als auch die W-Variante (-451) der Message abfragen, zumindest im Dialogstyle. Einen Code in Profan hab ich nicht für dich, wahrscheinlich geht eine sichere Abfrage nur mit Subclassing, also ab XProfan.

Rolf
Koch

Hi Rainer,

naja Frank hat ja schon geantwortet

Rolf

Hallo Frank,
hallo Rolf,

danke für die Antworten.

Frank,
ich hatte Deine Nachricht auch im Profanforum schon gelesen, nur noch nicht beantwortet. Auch diese Abfragen funktionieren bei mir nicht. Auch dieses SetActiveWindow usw. haben nicht den Erfolg den ich möchte und das Verhalten daß man von anderen Win-Programmen kennt. Im Übrigen hatte mich der Hinweis auf eine Assembler-Routine auch abgeschreckt, da ich davon nun ÜBERHAUPT NICHTS VERSTEHE!

Rolf,
meine Frage war eigentlich ob im ROC diese Events programmiert sind und ich sie nur nicht entdeckt habe. Denn ein Event ist ja da zu finden, der normale Klick auf einen Eintrag, und ich mir dachte wenn jemand so einen schönen ObjectCreator bastelt, daß dann die wichtigsten Events berücksichtigt sind.

Ich bin immer noch einer der ewig gestrigen PrFellow-Anwender (Sorry Rolf, wird wohl wirklich Zeit zu lernen und zum ROC umzuschwenken!) und hatte die Events auch in der WfEvents aufgenommen, leider ohne Erfolg. Dann kam eben der Versuch mit ROC da ich hoffte in einem Programm das immer UpToDate in der Entwicklung ist das Gesuchte zu finden.

Werde selber weiter versuchen mein Ziel zu erreichen, dennoch bin ich weiterhin für jede Hilfe dankbar.

MfG

Rainer Hoefs

Gug mal vielleicht hilft Dir das hier weiter:
Kompilieren Markieren Separieren

DEF GetTreeItem(1) sendmessage(@&(1),$110A,$0009,TVitem#)
DEF SetTreeItem(2) sendmessage(@&(1),$110B,$0009,@&(2))
DEF TreeHitTest(2) sendmessage(@&(1),4369,0,@&(2))
DEF GetTreeCount(1) Sendmessage(@&(1),$1105,0,0)
DEF TreeExpand(2) sendmessage(@&(1),$1102,$0002,@&(2))
DEF TreeColapse(2) sendmessage(@&(1),$1102,$0001,@&(2))

So nach dem Motto if getfocus(treeview) und GetTreeItem<>oldtreeitem dann erfolg

Salve, iF

Frank
Abbing

Hi,

ich hab hier einen Code von Richard Maurukas. Der ermittelt einfach nur das erste selektierte Item. Klappt hervoragend und kommt ganz ohne Notifies aus. Nicht die feine Art, aber funktioniert

...
Kompilieren Markieren Separieren

TreeView32-Control mit Imagelist (P)FairWare, FreeWare...
Für Profan² 6.0, 32 Bit
(c) 1998 Richard Maurukas
----------------------------------------------------------------
DEF GetModuleHandle(1) !"KERNEL32","GetModuleHandleA"
DEF LoadIcon(2) ! "USER32","LoadIconA" "&#","&"
DEF LoadBitmap(2) ! "USER32","LoadBitmapA"
DEF ImageList_Create(5) !"COMCTL32","ImageList_Create"
DEF ImageList_AddIcon(2) !"COMCTL32","ImageList_AddIcon"
DEF ImageList_Destroy(1) !"COMCTL32","ImageList_Destroy"
Declare hImageList&,hIcon&,Iconname#,Executehandle&
Declare Imagelist&,HIcon#
dim Iconname#,25
dim Hicon#,24
declare TVItem#
declare Treeview&
declare TVitemtext#
declare TVInsert#
dim Tvitem#,40
dim TVInsert#,48
dim TVitemtext#,255
Let Imagelist&=ImageList_Create(16,16,$0001,3,3) Imagelist erzeugen
Let ExecuteHandle&=GetModuleHandle(0)  Handle des laufenden Programms
Icon 0
String Iconname#,0="EDITOR"       Icon-Name
Let Hicon&=loadicon(Executehandle&,Iconname#) Handle des Icons ok
ImageList_AddIcon(Imagelist&,HIcon&)
Icon 1
String Iconname#,0="A"            Icon-Name
Let Hicon&=loadicon(Executehandle&,Iconname#) Handle des Icons ok
ImageList_AddIcon(Imagelist&,HIcon&)
Icon 2
String Iconname#,0="GESICHT"
Let Hicon&=loadicon(Executehandle&,Iconname#) Handle des Icons ok
ImageList_AddIcon(Imagelist&,HIcon&)

PROC TVITEM

    TVITEM und TVINSERT-Struktur-------------------------------
    String TVitemtext#,0=@$(4)      Der Text im Label
    long TVInsert#,0=@&(1)          TVins-Parent
    long Tvinsert#,4=@&(2)         TVins-Insert After
    long TVInsert#,8=$0027          mask IF_TEXT,IF_IMAGE,If_SelectedImage
    long TVInsert#,12=0            Htreeitem
    long TVInsert#,16=0             State
    long TVInsert#,20=0             StateMAsk
    long TVInsert#,24=Tvitemtext#   Adress of Label
    long TVInsert#,28=len(@$(4))   len of Label(länge GeDimt in Tvitemtext#)
    long TVInsert#,32=@&(2) 0      Image          z.B Ordner
    long TVInsert#,36=@&(3) 0      Selected Image z.B geöffneter Ordner
    long TVinsert#,40=0             cChildren
    long TVInsert#,44=0             Lparam
    -----------------------------------------------

ENDPROC

Declare TRoot&,TRoot1&,troot3&
Declare infotext&,ende%,Edithandle&
Window 0,0-350,440
Windowtitle "TreeViewControl32, (c) Richard Maurukas"
settruecolor 1
cls rgb(192,192,192)
let Infotext&=createtext(%Hwnd,"",40,0,250,20)
Let TreeView&=@control("SysTreeView32","",$5080002F,40,20,250,340,%Hwnd,200,%Hinstance)
sendmessage(TreeView&,$1109,0,Imagelist&) Associate the image list with the tree
TVITEM 0,0,1,"Richard Maurukas"
Let TRoot&= sendmessage(Treeview&,$1100,0,TVInsert#)  Insertitem in Root 0
TVITEM TRoot&,1,1,"präsentiert"
let TRoot1&=sendmessage(Treeview&,$1100,0,TVInsert#)  Insertitem in TRoot&
TVITEM TRoot&,0,0,"das TreeView32 Control"
let TRoot1&=sendmessage(Treeview&,$1100,0,TVInsert#)  Insertitem in TRoot&
TVITEM TRoot1&,1,1,"für Profan² Ver. 6.0 32 Bit"
sendmessage(Treeview&,$1100,0,TVInsert#)              Insertitem in TRoot1&
TVitem 0,1,0,"Roland G. Hülsmann"
let Troot3&=sendmessage(Treeview&,$1100,0,TVInsert#)  Insertitem in Root
TVitem Troot3&,2,2,"Entwickler von Profan²"
sendmessage(Treeview&,$1100,0,TVInsert#)              Insertitem in Troot3&
USefont "Times New Roman",18,0,1,1,0
sendmessage(Treeview&,$030,%Font,0)
settext infotext&,add$("Anzahl der Items im Control: ",
str$(Sendmessage(Treeview&,$1105,0,0))) TVM_Getcount
sendmessage(Treeview&,$1102,$0002,Troot&)     TV_Expand, Expand
sendmessage(Treeview&,$1102,$0002,Troot3&)    TV_Expand, Expand
sendmessage(Treeview&,$1102,$0001,Troot&)    TV_Expand, Colapse

Whilenot equ(Ende%,1)

    waitinput
    Das Selektierte Itemhandle im Treeview ermitteln
    TVM-Getnextitem=$110A, TVN_Caret=$0009, Eine Adresse=TVitem#
    Let Edithandle&= sendmessage(Treeview&,$110A,$0009,TVitem#)
    Settext infotext&,""
    Das ermittelte Handle mit dem erhaltenen Handle
    aus der Insertitem Message vergleichen und anzeigen.
    case equ(Troot&,Edithandle&):
    Settext infotext&,"Selected Text: Richard Maurukas"
    case equ(Troot1&,Edithandle&):
    Settext infotext&,"Selected Text: das TreeView32 Control"
    case equ(Troot3&,Edithandle&):
    Settext infotext&,"Selected Text: Roland G. Hülsmann"

wend

Dispose TVitemtext#
dispose TVInsert#
dispose TVitem#
ImageList_Destroy(hImagelist&)
Dispose Iconname#
Dispose Hicon#

Hallo Frank...

[quote:c1cab62e5c]
...wahrscheinlich geht eine sichere Abfrage nur mit Subclassing, also ab XProfan.
[/quote:c1cab62e5c]
Ich habe dein Messageproblem schon seit einiger Zeit mitverfolgt, habe leider aber noch zu wenig mit Treeviews gearbeitet, um dort wirklich mitreden zu können.
Was du da über die A und W Messages schreibst, scheint mir so, als würde da das Profan Messagehandling etwas durcheinanderschmeißen. Demnach ist das aber auch keine Sache für Subclassing. Hat Roland schon mal was zu dem Thema gesagt?

Um Subclassing überhaupt realisieren zu können, muß (soweit ich weiß) das Profan Messagehandling abgeschaltet werden. Ist allein mit dem Abschalten des Messahgehandlings die Ursache der Fehlfunktion aber nicht schon behoben und muß dann Subclassing überhaupt noch stattfinden?

Einge Messages werden nur von den jeweiligen Fensterclassen bearbeitet ( z.B. die CTLCOLOR Messages, WM_ERASEBKGND und WM_QUERRYENDSESSION). Nur für diese Messages ist Subclassing interessant. Gehört die von dir aufgeführte Message wirklich dazu oder ist das Profankram?

Nochmals zu Subclassing im allgemeinen (ich hoffe, ich langweile nicht):
Farbige Buttons, farbige Edits, Listboxen und vor allen Dingen das Abfangen des Herunterfahrens (sogar NotePad macht das), sind vernünfig nur über Subclassing zu realisieren.
Wenn ich Subclassing richtig verstanden habe, ist das eigentlich eine unkomplizierte und sehr einfache Sache.
Das man richtiges Subclassing vernünfig mit Profan realisieren kann (auch mit XProfan), ist aber äußerst schwierig. Eine Komponente, die Profan so extrem einfach in der Handhabung macht, würde komplett wegfallen - das Messagehandling => Chaos für Einsteiger.
Subclassing der Messages WM_QUERYENDSESSION und WM_ENDSESSION wäre demnach eine sehr notwendige Erweiterung für DLLs für Profan (damit müßte es eigentlich gehen, ohne das Messagehandling zu killen)...

Rolf
Koch

Hi Rainer,

Du musst Dich doch nicht Entschuldigen, daß Du ein Prfellow Nutzer bist

Leider hab ich ja einen Hauptberuf (Leider ist gut

- natürlich in Bezug auf die Sache) und wenn ich könnte würde ich gerne mehr Zeit in den ROC hängen. Ausserdem hab ich im Moment soviel um die Ohren - aber wer kennt dies nicht. Bin aber trotzdem an einem Update am arbeiten.
Aber nochmals: ROC ist ein Fenster- und Dialoghelfer und keine IDE.
Der Actionwriter ist nur da, um gewisse einfache Procs einzubauen um es später im Code einfacher zu haben.

Aber wie bereits oben erwähnt, haben die anderen hier ja einige Sachen zum Thema aufgezeigt.

Rolf

Frank
Abbing

Hallo Andreas,

> Ich habe dein Messageproblem schon seit einiger Zeit mitverfolgt, habe leider aber noch zu wenig mit Treeviews gearbeitet,
> um dort wirklich mitreden zu können.
> Was du da über die A und W Messages schreibst, scheint mir so, als würde da das Profan Messagehandling etwas durcheinanderschmeißen.
> Demnach ist das aber auch keine Sache für Subclassing. Hat Roland schon mal was zu dem Thema gesagt?

Ja, er sagte mir, er könne sich die Unterschiede zwischen Dialogmodus und dem normalen Windowmodus nicht recht erklären. Nur wird einmal die die Dialogproc angesprungen und einmal die Windowproc. Anscheinend macht Windows hier Unterschiede.

Messages werden normal im Superclassing abgefragt. Das ist die normale Abfrageroutine für Messages in einem Programmes. Verbiegt man den Zeiger auf die Fensterprozedur im nachhinein, spricht man vom Subclassing. Und genau in der Fensterprozedur werden Messages erkannt, verändert oder gelöscht. So ist es in anderen Sprachen. Profan ist etwas anderes, weil es die Messages für uns filtert und nur die wichtigsten an uns weiterleitet. Es bemuttert uns, was aber nicht immer erwünscht ist, und darum kann man dieses Verhalten abschalten.

> Um Subclassing überhaupt realisieren zu können, muß (soweit ich weiß) das Profan Messagehandling abgeschaltet werden.

Was ich eben ja schon sagte.

> Ist allein mit dem Abschalten des Messahgehandlings die Ursache der Fehlfunktion aber nicht schon behoben und muß dann Subclassing
> überhaupt noch stattfinden?

Ja. Weil Messages oft so schnell hintereinander kommen, das Profan die Werte zu langsam in seine Variablen schreibt. So werden viele Messages verschluckt, weil schon wieder aktuellere angekommen sind.

> Einge Messages werden nur von den jeweiligen Fensterclassen bearbeitet ( z.B. die CTLCOLOR Messages, WM_ERASEBKGND und WM_QUERRYENDSESSION).
> Nur für diese Messages ist Subclassing interessant. Gehört die von dir aufgeführte Message wirklich dazu oder ist das Profankram?

Alle Messages können subgeclassed werden. Die oben aufgeführte ist eine Notifymessage, also eine Sammelmessage, die unter WM_NOTIFY geführt wird.

> Nochmals zu Subclassing im allgemeinen (ich hoffe, ich langweile nicht):
> Farbige Buttons, farbige Edits, Listboxen und vor allen Dingen das Abfangen des Herunterfahrens (sogar NotePad macht das),
> sind vernünfig nur über Subclassing zu realisieren.
> Wenn ich Subclassing richtig verstanden habe, ist das eigentlich eine unkomplizierte und sehr einfache Sache.

Eigentlich ja.

> Das man richtiges Subclassing vernünfig mit Profan realisieren kann (auch mit XProfan), ist aber äußerst schwierig. Eine
> Komponente, die Profan so extrem einfach in der Handhabung macht, würde komplett wegfallen - das Messagehandling => Chaos
> für Einsteiger.

Richtig. Profan versucht die Sache für den User zu vereinfachen und läßt nur wichtige Messages durch. Will man alle Messages erhalten, dann ist dieses Profanverhalten abzustellen. Einige messages werden dennoch verschluckt. Subclassed man das Profanfenster aber, erhält man alle Messages, bevor Profan sie in die Finger bekommt.
Ich selber benutzte die Profan-Subclassing-Technik nicht, weil sie trotz allem immer noch zeilenweise interpretiert wird, wie das normale Programm auch. Darum verzögert es das ganze Messageshandling. Bestes Beispiel ist Andreas Miethes Splitterbar-Subclassingcode, der quälend langsam ist.
Von einer Dll aus aber macht Subclassing richtig Spass und es gibt keine Einschränkungen.

> Subclassing der Messages WM_QUERYENDSESSION und WM_ENDSESSION wäre demnach eine sehr notwendige Erweiterung für DLLs
> für Profan (damit müßte es eigentlich gehen, ohne das Messagehandling zu killen)...

Wenn du Profan2Cpp hast, wirst du sehr bald Dlls aus Profancode erzeugen können. Nativen Code.
Dann wird uns eine wahre Dll-Schwemme überrollen, jede Wette!

rainerhoefs

Hallo Frank, Andreas, Rolf und allen anderen die auf meine Frage geantwortet haben.

Mein Problem habe ich gelöst. Treevieweinträge werden ausgelesen, das Treeview verliert den Focus nach dem Doppelklick auf einen Eintrag, sodaß ich den erhaltenen String weiterverarbeiten kann, Auch wenn ich die Tatstautr benutze und mit + die einzelnen Einträge aufklappe, mit Hoch und Runter anwähle und mit Enter hole klappt alles, und jederzeit kann in den anderen Elemente geklickt und geschrieben werden. Menü und Toolbar funktionieren und so weiter. Ich habe nur die Events _OnEnter (_in der Api _OnReturn) und _OnDblclk in die WfEvents.Inc eingebaut. Damit war dann mein Problem gelöst.

Für all das was Ihr mit Assembler, SubClassing usw. geschrieben habt nochmals Danke, ist aber viel zu hoch für mich.

Frank,
Du erwähntest Prf2Cpp in der letzten Nachricht. Ja, ich habe die Testversion. Mein Profan Quellcode wird ohne jegliche Fehler auch Übersetzt. Wenn ich den allerdings mit DevC++ 4.* kompilieren will funktioniert überhaupt nichts. Manchmal gelingt es das Programm im RUN-Modus zum Laufen zu bringen. Allerdings wird dann der Dialog der beim Anklicken eines Toolbaricons erscheinen sollte nicht gestartet. Gibt es irgendwo genaue Angabe wie ich den Compiler einstellen muß damit auch eine EXE entsteht. (in der Form das auch ich es verstehe.) Denn das würd ich gerne noch kapieren und anwenden, da schon im Run-modus das Programm (Leider nur das HWND) super schnell läuft!

Danke im Voraus

Rainer Hoefs

22.03.2005 ▲

Frank
Abbing

Hallo Rainer,

interessant, ich selber benutze auch den DevC++4 als Compiler, ohne Probleme. Ist wahrscheinlich nur eine Einstellungssache. Am besten fragst du mal direkt den Sebastian König im offiziellen Profan2Cpp Forum: [...]

22.03.2005 ▲