Deutsch
Bugs und vermeintliche

Problem mit Active-X Beispielen von Uwe Pascal N.

 

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:
KompilierenMarkierenSeparieren
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:
KompilierenMarkierenSeparieren
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
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.
 
30.06.2008  
 




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:  [...] 
30.06.2008  
 




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  [...]  ?
 
30.06.2008  
 




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
 
01.07.2008  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

9.166 Betrachtungen

Unbenanntvor 0 min.
RudiB.17.03.2022
Andre Rohland30.12.2013
Pedro Miguel26.08.2013
Georg Hovenbitzer28.05.2013
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie