XProfan

RGH

Dieter Zornow

Dann poste doch bitte mal ein möglichst kleines Beispiel, damit ich das nachvollziehen 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

29.06.2008 ▲

Dieter
Zornow

Ich habe dir etwas per E-Mail geschickt, da Includes und eigene Headerdateien verwendet werden. Die Beispiele müssten aber auch hier im Forum downloadbar sein unter ActiveX

Gruss

Dieter

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

29.06.2008 ▲

RGH

Hallo, ich glaube ich habe die Ursache gefunden. Offensichtlich macht sich Pascal die nicht dokumentierte (und somit nicht garantierte) statische Speicherverwaltung von XProfan bis einschließlich Version 10 zu Nutze. Als Beispiel nutze ich einen gekürzten Quelltext aus seiner Feder. Bis XProfan 10 funktioniert folgender Quelltext:
Kompilieren Markieren Separieren

window 100,10-500,500
usermessages 16
 $H Windows.ph
 $H OCX.ph
 $I OCX.inc
declare ATL&,Var#,Disp#,IID#
ocxInit()
declare Object&,Control&
ocxCreate(MSCAL.Calendar.7,%hwnd,10,100,350,250,addr(Object&),addr(Control&))
ocxMethod(Object&,Today)
numwidth 3

while 1

    locate 0,0
    print Tag   ,ocxGet(Object&,Day)
    print Monat ,ocxGet(Object&,Month)
    print Jahr  ,ocxGet(Object&,Year)
    waitinput
    case %umessage=16:break

endwhile

ocxMethod(Object&,AboutBox)
destroywindow(Control&)
ocxDeInit()

Der Quelltext funktioniert natürlich nur unter der Annahme, dass die Speicheradresse der Variablen Object& und Control& unveränderlich ist, was bis XProfan 10 auch zufällig so war. XProfan 11 zeigt hier mehr Dynamik, so das folgende kleine Änderung notwendig wird:
Kompilieren Markieren Separieren

window 100,10-500,500
usermessages 16
 $H Windows.ph
 $H OCX.ph
 $I OCX.inc
declare ATL&,Var#,Disp#,IID#
ocxInit()
declare Object&,Control&
declare c#, o#
dim c#,4
dim o#,4
ocxCreate(MSCAL.Calendar.7,%hwnd,10,100,350,250,o#,c#)
Object& = Long(O#,0)
Control& = Long(C#,0)
ocxMethod(Object&,Today)
numwidth 3

while 1

    locate 0,0
    print Tag   ,ocxGet(Object&,Day)
    print Monat ,ocxGet(Object&,Month)
    print Jahr  ,ocxGet(Object&,Year)
    waitinput
    case %umessage=16:break

endwhile

ocxMethod(Object&,AboutBox)
destroywindow(Control&)
ocxDeInit()

Mach beachte die Bereichsvariablen O# und C#, um das Ergebnis von ocxCreate() abzuholen. Und schon funktioniert es auch unter XProfan 11. Ich nehme an, dass auch die anderen Beispiele von UwePascal ebenso einfach anzupassen 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

Dieter
Zornow

Ok, danke dann ist es ja gut, ich hatte nur mal ein bischen rum experimentiert, dann stürtze jedes Programm ab und ich dachte, das ist ein Bug in XProfan 11, so kann mansich irren.

Gruß

Dieter

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

Frank
Abbing

Offensichtlich macht sich Pascal die nicht dokumentierte (und somit nicht garantierte) statische Speicherverwaltung von XProfan bis einschließlich Version 10 zu Nutze.

Da ist er nicht allein. Willst du sagen, diese für mich ebenfalls gängige Praxis ist ab sofort nicht mehr gestattet? Auch nicht bei herkömmlicher API? Ist doch Gang und Gebe bei diversen Dll-Funktionen den Zeiger auf ein LongInt zu übergeben.

Sebastian
König

Hallo Roland,

ich finde das neue Verhalten auch ziemlich irritierend... Auch wenn es streng genommen stimmt, dass das nicht explizit dokumentiert war, sollte man sich mit Blick auf andere Sprachen doch darauf verlassen können, dass sich die Adresse einer Variablen nicht ändert (zumindest solange sie gültig ist, also bei globalen Variablen dauerhaft und bei lokalen für die Dauer des Prozedur- bzw. Funktionsaufrufs). Wenn das nicht mehr gegeben ist, könnte man etwas überspitzt fragen, welchen Sinn Addr() für normale Variablen überhaupt noch hätte...

Natürlich ist die dynamische Adressverwaltung auf der anderen Seite eine feine Sache - kannst Du es vielleicht so einrichten, dass Variablen, deren Adresse ermittelt wird, vor einem Verschieben im Speicher geschützt werden?

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

RGH

Hallo!

Zunächst einmal: Die Übergabe eines Wertes über die Adresse einer Variablen an eine API-Funktion ist grundsätzlich kein Problem. Probleme können offensichtlich nur dann in ganz speziellen Fällen auftauchen, wenn über diese Adresse Werte zurückgegeben werden.

Bislang hatte ich zum Abspeichern der Variablen in Delphi ein statisches Array benutzt. Daher war die anzahl der Variablen auch immer beschränkt, da das Array zum Programmbeginn erzeugt wurde.
In XProfan 11 verwende ich die Open Arrays in Delphi und die benutzen offensichtlich eine etwas andere Speicherverwaltung.

Ich schaue mal, ob ich da auf die Schnelle noch was drehen kann, will aber nichts versprechen.

Das Problem scheint ja nur in sehr speziellen Fällen aufzutreten. Im Normalfall bleibt die Adresse einer Variablen ja tatsächlich immer noch bestehen. Das Problem scheint ja, da es erst jetzt nach über einem halben Jahr seit der ersten Subscriptionsversion aufgetaucht ist, nur extrem selten aufzutreten. Möglicherweise tatsächlich nur bei Active X.

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

RGH

Willst du sagen, diese für mich ebenfalls gängige Praxis ist ab sofort nicht mehr gestattet? Auch nicht bei herkömmlicher API? Ist doch Gang und Gebe bei diversen Dll-Funktionen den Zeiger auf ein LongInt zu übergeben.

Bei herkömmlicher API scheint es weiterhin keinerlei Probleme zu geben. So wie es nach weiteren Experimenten aussieht, ändert sich auch tatsächlich nicht die Adresse der Variablen. Wie ich oben schon erwähnte: Vermutlich tritt das Problem nur in seltenen, ganz speziellen Fällen auf.

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

Nutzt Delphi da Heaps [...]

RGH

... und so wie es aussieht, laufen auf meinem Rechner zu Hause (XP Pro SP3) die Beispiele von Uwe Pascal werder unter XProfan 10 noch unter XProfan 11. Es kommt immer die Meldung CallMethod - Unbekannter Name. (Ja, ich habe die ComCtl32.ocx registriert ....) In der Firma (XP Pro SP2 hat es geklappt.)

Dann muß ich mich wohl doch anderen Themen zuwenden ...

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

Uwe
''Pascal''
Niemeier

Hallo Leute!

Zunächst mal: Ich habe im Moment weder XP SP3 noch XProfan 11 zur Verfügung, darum kann ichs nicht selbst testen.

Aber: Die von Roland reklamierten Variablen haben in dieser Version der OCX-Routinen direkt nichts mit den ActiveX-Funktionen zu tun:
Kompilieren Markieren Separieren

proc ocxCreate----------------------------------ocxCreate-------------------------------

    parameters ProgID$,Wnd&,xa%,ya%,xb%,yb%,ObjAddr&,CtrlAddr&
    declare Control&,IUnknown&,Object&
    Control&=control(AtlAxWin,ProgID$,$50000000,xa%,ya%,xb%,yb%,Wnd&,0,0,0)
    ~AtlAxGetControl(Control&,addr(IUnknown&))
    Object&=QueryInterface(IUnknown&,~IID_IDispatch)
    CallMethod(IUnknown&,~Release)
    long ObjAddr&,0=Object&
    long CtrlAddr&,0=Control&
    endproc---------------------------------------------------------------------------------
    declare Object&,Control&
    ocxCreate(MSCAL.Calendar.7,%hwnd,10,100,350,250,addr(Object&),addr(Control&))

Die beiden Pointer kommen in der Proc als ObjAddr& und CtrlAddr& an, Object& und Control& werden lokal nochmal deklariert und am Ende der Proc werden die - als Parameter übergebenen - Pointer mit LONG gefüllt.

Das Problem könnte also auch in der direkten Übergabe von
addr(Variable&) als Parameter für eine Prozedur liegen oder in der lokalen Deklaration einer global bereits vorhandenen Variable...

PS: Im Beispiel wird Version 1 der OCX-Routinen verwendet. Wie sieht es denn mit Version 2 aus?

SeeYou
Pascal

01.07.2008 ▲