| |
|
|
Dieter Zornow | Ich denke es ist noch ein Problem in XProfan 11, habe gerade auch nochmals die OCX - Beispiele von Uwe Pascal N. getestet. Unter XProfan 10 läuft alles noch einwandfrei. Unter XProfan 11 RC 8 nur Abstürze bei jedem Beispiel.
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 | Dieter Zornow
Ich denke es ist noch ein Problem in XProfan 11, habe gerade auch nochmals die OCX - Beispiele von Uwe Pascal N. getestet. Unter XProfan 10 läuft alles noch einwandfrei. Unter XProfan 11 RC 8 nur Abstürze bei jedem Beispiel.
Gruss
Dieter
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: KompilierenMarkierenSeparierenwindow 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: KompilierenMarkierenSeparierenwindow 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 | 30.06.2008 ▲ |
|
|
|
|
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 | 30.06.2008 ▲ |
|
|
|
|
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 |
|
|
| |
|
|
|
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 | 30.06.2008 ▲ |
|
|
|
|
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 | 30.06.2008 ▲ |
|
|
|
|
| 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 | 30.06.2008 ▲ |
|
|
|
|
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: KompilierenMarkierenSeparieren
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 |
|
|
| |
|
|