Français
Bugs et vermeintliche

Problem avec Active-X Beispielen de Uwe Pascal N.

 

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éparation
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(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éparation
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

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




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
 
Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage:  [...] 
Alte Profan²-Seite:  [...] 
30.06.2008  
 




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




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
 
01.07.2008  
 




répondre


Topictitle, max. 100 marque.
 

Systemprofile:

ne...aucune Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

s'il te plaît s'inscrire um une Beitrag trop verfassen.
 

Options du sujet

9.082 Views

Untitledvor 0 min.
RudiB.17.03.2022
Andre Rohland30.12.2013
Pedro Miguel26.08.2013
Georg Hovenbitzer28.05.2013
plus...

Themeninformationen



Admins  |  AGB  |  Applications  |  Auteurs  |  Chat  |  protection des données  |  Télécharger  |  Entrance  |  Aider  |  Merchantportal  |  Empreinte  |  Mart  |  Interfaces  |  SDK  |  Services  |  Jeux  |  cherche  |  Support

un projet aller XProfaner, qui il y a!


Mon XProfan
Privé Nouvelles
Eigenes Ablageforum
Sujets-La liste de voeux
Eigene Posts
Eigene Sujets
Zwischenablage
Annuler
 Deutsch English Français Español Italia
Traductions

protection des données


Wir verwenden Cookies seulement comme Session-Cookies à cause de qui technischen Notwendigkeit et chez uns gibt es aucun Cookies de Drittanbietern.

si du ici sur unsere Webseite klickst ou bien navigierst, stimmst du unserer Erfassung de Informationen dans unseren Cookies sur XProfan.Net trop.

Weitere Informationen trop unseren Cookies et en supplément, comment du qui Kontrolle par-dessus behältst, findest du dans unserer nachfolgenden Datenschutzerklärung.


d'accordDatenschutzerklärung
je voudrais keinen Cookie