XProfan

Deutsch

Nicht-XPSE:

DECLARE __cf1&,__cf2&
Def __cf1(2) !KERNEL32,GetProcAddress
Def __cf2(1) !KERNEL32,GetModuleHandleA
__cf1&=__cf1(__cf2(user32.dll),SetWindowLongA)
__cf2&=__cf1(__cf2(user32.dll),CallWindowProcA)
 $DEFINE XPSE
CLS
VAR _OWP&=call(__cf1&,%HWND,-4,PROCADDR(WPROC,4))
PRINT LOADFILE$(,)
WAITINPUT
END

proc WPROC

    PARAMETERS WND&, MSG&, WPARAM&, LPARAM&
    call(__cf2&,_OWP&,WND&, MSG&, WPARAM&, LPARAM&)

endproc

Kompilieren Markieren Separieren

cls
var _owp&:=setwindowlong(hwnd,gwl_wndproc,procaddr(wproc,4))
print loadfile$(,)
waitinput
end

proc wproc(Wnd&, Msg&, Wparam&, Lparam&)

    callwindowproc(_owp&,Wnd&, Msg&, Wparam&, Lparam&)

endproc

Der Source zeigt (glaube ist aber ein altes Problem!) das LoadFile$ nicht den gewünschten Wert zurückgibt.

Ich will hier nicht auf dem Problem rumhacken aber es einfach nochmals ansprechen. Ich denke mit ChooseDir verhält es sich ähnlich.

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Wenn man ins Profan-interne Messagehandlich eingreift, etwa durch den Fastmode oder mittels eines Umbiegens der Windows-Prozeduren, darf man sich nicht wundern, wenn die vordefinierten Dialoge nicht mehr wie gewünscht funktionieren, da sie auf das Profan-interne Messagehandling angewiesen sind.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Wenn man sich aber tzrotzdem das Schreiben eigener Dialoge ersparen will, kann man ja vor dem Aufruf von LoadFile$ die ursprüngliche Windows-Prozedur (findet sich exakt zu diesem Zweck in &WinProc) einsetzen und direkt danach wieder auf die eigene umschalten, etwa so:

Kompilieren Markieren Separieren

DECLARE __cf1&, __cf2&, MyWProc&
Def __cf1(2) !KERNEL32,GetProcAddress
Def __cf2(1) !KERNEL32,GetModuleHandleA
__cf1&=__cf1(__cf2(user32.dll),SetWindowLongA)
__cf2&=__cf1(__cf2(user32.dll),CallWindowProcA)

proc WPROC

    Parameters WND&, MSG&, WPARAM&, LPARAM&
    call(__cf2&,_OWP&,WND&, MSG&, WPARAM&, LPARAM&)

endproc

Proc WLoadFile

    Parameters titel$, filter$
    call(__cf1&,%HWND,-4,&winproc)
    var erg$ = LoadFile$(titel$, filter$)
    call(__cf1&,%HWND,-4,MyWProc&)
    return erg$

EndProc

Hauptprogramm
-------------
CLS
MyWProc& = PROCADDR(WPROC,4)
VAR _OWP&=call(__cf1&, %HWND, -4,MyWProc&)
PRINT WLoadFile(,)
WAITINPUT
call(__cf1&,%HWND,-4,&winproc)
END

Ach ja: Vor dem End muß die Original-Prozedur auch noch eingewsetzt werden, da es sonst beim Programmende zum Absturz kommen kann.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

OK - leuchtet ein. Man muss also für jedes Control welches man SubClasst vor dem Aufruf der vordefinierten Dialoge die originalWinProzedur wiederherstellen - das deckt sich auch mit meinen Erfahrungen.

Ich finde ein Hinweis in der Hilfedatei bei den Vordefinierten Dialogen und bei ProcAddr ist angebracht und kann viele Verzweiflungen im Vorraus verhindern.

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Ja, ich sollte es in der Hilfe an passender Stelle erwähnen.
Die geschickteste Möglichkeit wäre sicher, keine vordefinierten Dialoge in solchen Programmen zu verwenden. Wer die Windowsprozedur selbst schreibt, schafft es sicher auch, die Dialoge selbst zu schreiben. ;)

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Naja es geht tatsächlich doch noch etwas eleganter - besonders wenn man so faul ist wie ich es bin!

Um es kurz zu veranschaulichen - ich beschäftige einfach die gleiche Exe mit neuem Prozess für die nötige Aufgabe...

Kompilieren Markieren Separieren

//nur zur Veranschaulichung!
include usermessages.pcu = um.
include pipe.pcu = pipe.
include scrollarea.inc

if %parcount

    select par$(1)

        caseof loadfile

        app.loadfile

        caseof browsefolder

        app.browseForFolder
        otherwise
        end

    endselect

endif

var hwnd:=new(ScrollArea,0,(%maxx/2-305),(%maxy/2-300),610,430,610-18,600,sa_complete | SA_DESKTOPISDIALOG - SA_MINIMIZEBOX,apptitle)
var _owp&:=setwindowlong(hwnd,gwl_wndproc,procaddr(wproc,4))
print hwnd.loadfile$(,)
waitinput
end

proc wproc(Wnd&, Msg&, Wparam&, Lparam&)

    callwindowproc(_owp&,Wnd&, Msg&, Wparam&, Lparam&)

endproc

proc hwnd.loadfile(desc$,mask$)

    enablewindow hwnd::window&,0
    var sid$:=str$(gettickcount)
    var pipe&:=pipe.create(sid$)
    pipe.push pipe&,desc$
    pipe.push pipe&,mask$
    pipe.push pipe&,str$(%hwnd)
    shell par$(0)+ loadfile +sid$
    um.add 7788

    while pipe.get(pipe&)<>done

        waitinput

    wend

    um.sub 7788
    sleep 100
    pipe.pop pipe&
    var result$:=pipe.pop(pipe&)
    pipe.close pipe&
    enablewindow hwnd::window&,1
    setactivewindow(hwnd::window&)
    return result$

endproc

proc app.loadfile

    var sid$:=par$(2)
    var pipe&:=pipe.create(sid$)
    var desc$:=pipe.pop(pipe&)
    var mask$:=pipe.pop(pipe&)
    var hwnd&:=val(pipe.pop(pipe&))
    var result$:=loadfile$(desc$,mask$)
    pipe.push pipe&,done
    pipe.push pipe&,result$
    pipe.close pipe&
    sendmessage(hwnd&,7788,0,0)
    end

endproc

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Frank
Abbing

Man muss also für jedes Control welches man SubClasst vor dem Aufruf der vordefinierten Dialoge die originalWinProzedur wiederherstellen - das deckt sich auch mit meinen Erfahrungen.

Aber nicht mit meinen. Dort gab es nur mit dem Hauptfenster ab und an Probleme, nie aber mit anderen Controls. Was ja auch logisch ist, da sich der der Fastmode nur auf %hwnd bezieht.

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

RGH

Wir haben hier zwei Tatbestände vorliegen, die direkt in XProfan eingreifen: Der Fastmode und die Umdefinierung der Windowsprozeduren.

Genau genommen bezieht sich der Fastmode nur auf das XProfan-interne Messagehandling, daß durch diesen weitgehend abgeschaltet wird. Das kann (muß aber nicht in jedem Fall) Auswirkungen auf die vordefinierten Dialoge haben.

Das Zweite sind die Windowsroutinen. Davon hat XProfan 4 Strück: Hauptfenster (&WinProc), Hauptfenster im Dialogstil (&WinDProc), Dialogfenster mit @Create(Dialog (&DlgProc) und Fenster mit @Create(Window (&DlgWProc). Die vordefinierten Dialoge haben als Elternfenster immer das Hauptfenster, wenn es denn existiert, oder einfach 0.

Wie auch immer: Wer am offenen Herzen von XProfan operiert, muß damit rechnen, den einen oder anderen Bypass legen zu müssen. ;)

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

23.10.2006 ▲

Vollständiges Zitat

Absatzweise zitieren Zeilenweise zitieren

Frank Abbing

Man muss also für jedes Control welches man SubClasst vor dem Aufruf der vordefinierten Dialoge die originalWinProzedur wiederherstellen - das deckt sich auch mit meinen Erfahrungen.

Aber nicht mit meinen. Dort gab es nur mit dem Hauptfenster ab und an Probleme, nie aber mit anderen Controls. Was ja auch logisch ist, da sich der der Fastmode nur auf %hwnd bezieht.

Na dann schau Dir mal das hier an Frank, ich denke das kann Deine Meinung ändern:

Kompilieren Markieren Separieren

 {$cleq}
cls
var listbox&:=createlistbox(hwnd,,10,10,100,100)
var _owp&:=setwindowlong(listbox&,gwl_wndproc,procaddr(wproc,4))
print loadfile$(,)
waitinput
end

proc wproc(Wnd&, Msg&, Wparam&, Lparam&)

    callwindowproc(_owp&,Wnd&, Msg&, Wparam&, Lparam&)

endproc

Hier wird die listbox& gesubclasst - und Loadfile verhält sich dämlich wie erwartet...