| |
| |
|
Dieter
Zornow | je denke c'est encore un Problem dans XProfan 11, habe justement aussi nochmals qui OCX - Beispiele de Uwe Pascal N. getestet. sous XProfan 10 fonctionne alles encore einwandfrei. sous XProfan 11 RC 8 seulement Abstürze chez chaque 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
je denke c'est encore un Problem dans XProfan 11, habe justement aussi nochmals qui OCX - Beispiele de Uwe Pascal N. getestet. sous XProfan 10 fonctionne alles encore einwandfrei. sous XProfan 11 RC 8 seulement Abstürze chez chaque Beispiel.
Gruss
Dieter
ensuite Poste doch s'il te plaît la fois un possible kleines Beispiel, avec cela je cela nachvollziehen peux.
Salut
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 | j'ai dir quelque chose per E-Mail envoyé, là Comprend et eigene Headerdateien verwendet volonté. qui Beispiele müssten mais aussi ici im Forum downloadbar son sous 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 | allô, je crois j'ai qui Ursache trouvé. Offensichtlich pouvoir sich Pascal qui pas dokumentierte (et somit pas garantierte) statische Gestion de la mémoire de XProfan jusqu'à einschließlich Version 10 trop Nutze. comme Beispiel nutze je une gekürzten Voir le texte source aus seiner plume. jusqu'à XProfan 10 funktioniert suivant Voir le texte source:
KompilierenMarqueSéparationwindow 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(n class=s2>)
qui Voir le texte source funktioniert naturellement seulement sous qui Annahme, dass qui Speicheradresse qui Variablen Object& et Control& unveränderlich ist, quoi jusqu'à XProfan 10 aussi zufällig so était. XProfan 11 zeigt ici plus Dynamik, so cela folgende kleine Changement notwendig wird:
KompilierenMarqueSéparationwindow 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
tandis que 1
locate 0,0
imprimer journée ,ocxGet(Object&,Day)
imprimer mois ,ocxGet(Object&,Month)
imprimer l'an ,ocxGet(Object&,Year)
waitinput
cas %umessage=16:pause
endwhile
ocxMethod(Object&,AboutBox)
destroywindow(Control&)
ocxDeInit()
Mach beachte qui Bereichsvariablen O# et C#, um cela Ergebnis de ocxCreate() abzuholen. et déjà funktioniert es aussi sous XProfan 11. je prends à, dass aussi qui anderen Beispiele de UwePascal ebenso simple anzupassen sommes.
Salut
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, merci ensuite ist es oui bien, je hatte seulement la fois un un peu rum experimentiert, ensuite stürtze chaque Programme ab et je dachte, c'est un Bug dans XProfan 11, so peux mansich irren.
Salut
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 pouvoir sich Pascal qui pas dokumentierte (et somit pas garantierte) statische Gestion de la mémoire de XProfan jusqu'à einschließlich Version 10 trop Nutze.
le voilà pas seul. veux du dire, cet pour mich également gängige Praxis ist ab tout de suite pas plus gestattet? aussi pas chez herkömmlicher API? Ist doch couloir et Gebe chez diversen Dll-Funktionen den aiguille sur un LongInt trop transfert.  |
|
| |
| |
| |
|
|
Sebastian
König | allô Roland,
je trouve cela neue Verhalten aussi assez irritierend... aussi si es streng pris stimmt, dass cela pas explizit dokumentiert était, sollte on sich avec perspective sur autre Sprachen doch puis sortir de peut, dass sich qui Adresse einer Variablen pas ändert (zumindest solange vous gültig ist, alors chez globalen Variablen dauerhaft et chez lokalen pour qui la durée des Procédure- bzw. Funktionsaufrufs). si cela pas plus gegeben ist, pourrait on quelque chose überspitzt fragen, welchen Sinn Addr() pour normale Variablen überhaupt encore hätte...
Bien sûr ist qui dynamische Adressverwaltung sur qui anderen page une feine l'affaire - peux Du es peut-être so einrichten, dass Variablen, en Adresse ermittelt wird, avant einem Déplacer im grenier geschützt volonté?
MfG
Sebastian |
|
| |
| |
| |
|
|
RGH | allô!
Zunächst einmal: qui Übergabe eines Wertes sur qui Adresse einer Variablen à une API-Funktion ist grundsätzlich ne...aucune Problem. Probleme peut offensichtlich seulement ensuite dans entier speziellen Fällen auftauchen, si sur cet Adresse Werte retour volonté.
Bislang J'ai eu zum Abspeichern qui Variablen dans Delphi un statisches Array benutzt. Daher était qui anzahl qui Variablen De toute façon beschränkt, là cela Array zum Programmbeginn erzeugt wurde.
dans XProfan 11 verwende je qui Open Arrays dans Delphi et qui benutzen offensichtlich une quelque chose autre Gestion de la mémoire.
je schaue la fois, si je là sur qui Schnelle encore quoi drehen peux, veux mais rien versprechen.
cela Problem scheint oui seulement dans très speziellen Fällen aufzutreten. Im Normalfall bleibt qui Adresse einer Variablen oui réellement toujours bestehen. cela Problem scheint oui, là es seulement maintenant pour sur einem halben l'an depuis qui ersten Subscriptionsversion aufgetaucht ist, seulement extrem selten aufzutreten. Möglicherweise réellement seulement chez Active X.
Salut
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 |
veux du dire, cet pour mich également gängige Praxis ist ab tout de suite pas plus gestattet? aussi pas chez herkömmlicher API? Ist doch couloir et Gebe chez diversen Dll-Funktionen den aiguille sur un LongInt trop transfert.
chez herkömmlicher API scheint es weiterhin keinerlei Probleme trop donner. So comme pour weiteren Experimenten aussieht, ändert sich aussi réellement pas qui Adresse qui Variablen. comment je dessus déjà erwähnte: Vermutlich tritt cela Problem seulement dans seltenen, entier speziellen Fällen sur.
Salut
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 là Heaps [...]  ? |
|
| |
| |
| |
|
|
RGH | ... et so comme aussieht, courir sur meinem calculateur trop Hause (XP Pro SP3) qui Beispiele de Uwe Pascal werder sous XProfan 10 encore sous XProfan 11. Es venez toujours qui annonce CallMethod - Unbekannter nom. (oui, j'ai qui ComCtl32.ocx registriert ....) dans qui Firma (XP Pro SP2 hat es geklappt.)
ensuite doit je mich wohl doch anderen Sujets zuwenden ...
Salut
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 | allô gens!
Zunächst la fois: j'ai im Moment weder XP SP3 encore XProfan 11 zur Disposition, tout autor peux ego pas selbst testen.
mais: qui de Roland reklamierten Variablen avons dans cette Version qui OCX-Routinen direct rien avec den ActiveX-Funktionen trop 1faire:
KompilierenMarqueSéparation
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&)
qui beiden Pointer venons dans qui Proc comme ObjAddr& et CtrlAddr& à, Object& et Control& volonté bistrot nochmal deklariert et am Ende qui Proc volonté qui - comme paramètre übergebenen - Pointer avec LONG pleine.
cela Problem pourrait alors aussi dans qui direkten Übergabe de
addr(Variable&) comme paramètre pour une Procédure liegen ou bien dans qui lokalen Deklaration einer global bereits vorhandenen Variable...
PS: Im Beispiel wird Version 1 qui OCX-Routinen verwendet. comment sieht es car avec Version 2 aus?
SeeYou
Pascal |
|
| |
| |
| |
|
(446)
Deutsch
English
Français
Español
Italia