Français
Bugs et vermeintliche

Problem avec Active-X Beispielen de Uwe Pascal N.

 
- page 1 -



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  
 



 
- page 1 -


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  
 



 
- page 2 -



RGH
Salut,

j'ai mir qui l'affaire gestern soir encore la fois genauer angeschaut. c'est aussi weiterhin so, dass une variable au cours de ihrer Gültigkeit ses Adresse pas ändert. de daher alors une Entwarnung!

cela Problem liegt dans Pascals Créer-Routine, bzw. qui Übergabe qui Variablen aus cette zurück:
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--------------------------------------------------------------------------------span>

Über PARAMETERS volonté qui beiden Adressen dans den lokalen Variablen ObjAddr& et CtrlAddr& gespeichert. en Adressen volonté mais avec sortir de qui Procédure ungültig. dans XProfan 11 avons Object& et Control& la valeur 0 ... quoi ensuite unweigerlich zum Crash führt.
voudrais on plusieurs Werte aus einer Procédure zurückerhalten wempfiehlt sich toujours qui Weg sur une struktur ou bien sur un objet, là - comment dans nahezu allen Sprachen - Strukturen et Objekte per Adresse transfert volonté. So sieht qui angepaßte Créer-Procédure aus:
KompilierenMarqueSéparation
proc ocxCreate----------------------------------ocxCreate-------------------------------

    parameters ProgID$,Wnd&,xa%,ya%,xb%,yb%,Uebergabe#
    declare IUnknown&
    Uebergabe#.Control&=control(AtlAxWin,ProgID$,$50000000,xa%,ya%,xb%,yb%,Wnd&,0,0,0)
    ~AtlAxGetControl(Uebergabe#.Control&,Addr(IUnknown&))
    Uebergabe#.Object&=QueryInterface(IUnknown&,~IID_IDispatch)
    CallMethod(IUnknown&,~Release)
    endproc---------------------------------------------------------------------------------

aussi qui Procédure QueryInterface() doit entsprechend ajusté volonté (Aufruf de CallMethod()):
KompilierenMarqueSéparation
proc QueryInterface-------------------------------------------------------------

    parameters IFace1&,IID$
    declare IFace2#,Error&
    dim IFace2#,4
    StringToGUID(IID$,IID#)
    Error&=CallMethod(IFace1&,0,IID#,IFace2#)
    cas Error&<0:ErrorMessage(Error&,QueryInterface)
    CallMethod(IFace1&,~Release)
    return long(IFace2#, 0)
    endproc-----------------------------------------------------------------------

et so eh bien cela Beispielprogramm:
KompilierenMarqueSéparation
window 100,10-500,500
usermessages 16
 $H Windows.ph
 $H OCX.ph
 $I OCX.inc
seulement zur Demo. normalement serait on qui Übergabestruktur dans OCX.ph définir
Struct SUebergabe = Object&, Control&
declare U#
dim U#, SUebergabe
declare ATL&,Var#,Disp#,IID#
ocxInit()
ocxCreate(MSCAL.Calendar.7,%hwnd,10,100,350,250,U#)
ocxMethod(U#.Object&,Today)
numwidth 3

tandis que 1

    locate 0,0
    imprimer journée   ,ocxGet(U#.Object&,Day)
    imprimer mois ,ocxGet(U#.Object&,Month)
    imprimer l'an  ,ocxGet(U#.Object&,Year)
    waitinput
    cas %umessage=16:pause

endwhile

ocxMethod(U#.Object&,AboutBox)
destroywindow(U#.Control&)
ocxDeInit()

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
01.07.2008  
 




RGH
encore kurz zur Erklärung pour Insider:

dans Xrofan 11 volonté réellement avec sortir de einer Procédure qui Adressen qui lokalen Variablen wieder ungültig et qui entsprechende grenier wird wieder libre gegeben.

jusqu'à einschließlich XProfan 10 wurde qui grenier pour alle möglichen Variablen oui beim Start zur Disposition gestellt.* Beim sortir de qui Procédure wurde zwar qui aiguille sur qui dernier Variable zurückgesetzt, so dass sur qui lokalen Variablen qui Procédure pas plus zugegriffen volonté konnte et qui grenier pour qui Deklaration neuer Variablen wieder zur Disposition stand, mais qui grenier wurde pas freigegeben. et so longtemps cette pas par neue Declares genutzt wurde, blieben qui alten Werte là stehen.

Salut
Roland

* chez Cordes, Arrays et Bereichen allerdings seulement qui aiguille sur den grenier ... mais cela wäre maintenant un d'autre Thema ...
 
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
01.07.2008  
 




Sebastian
König
RGH
Über PARAMETERS volonté qui beiden Adressen dans den lokalen Variablen ObjAddr& et CtrlAddr& gespeichert. en Adressen volonté mais avec sortir de qui Procédure ungültig. dans XProfan 11 avons Object& et Control& la valeur 0 ... quoi ensuite unweigerlich zum Crash führt.


cela Argument verstehe je irgendwie pas... dans den Parametern ObjAddr& et CtrlAddr& volonté doch qui Adressen de globalen Variablen transfert (siehe Pascals Code dessus). quoi oui c'est ca ist ensuite cela Problem chez einer Zuweisung qui forme long ObjAddr&,0=Object&? Worauf oui c'est ca ObjAddr& eh bien zeigt, pouvoir aus Sicht qui Procédure oui keinen Unterschied et dass Object& eh bien une lokale Variable ist, pourrait aussi aucun rôle spielen.

So comment je qui Beschreibung verstehe, ist cela ganze doch äquivalent trop einem solchen Beispiel:
KompilierenMarqueSéparation
proc Test

    parameters pA&,pB&
    long pA&,0 = 123
    long pB&,0 = 456

endproc

cls
declare a&,b&
Test Addr(a&),Addr(b&)
print a&,b&
waitkey
Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage:  [...] 
Alte Profan²-Seite:  [...] 
01.07.2008  
 




RGH
oui, rOlf, je vermute tu as droite: mon Erklärung était quelque chose trop kurz gegriffen.
Tatsache ist, dass qui entsprechend veränderten et de mir geposteten Quellcodes aussi sous XProfan 11 einwandfrei marcher.
(Zumindest ici am Arbeitsplatz-PC. Zuhause sur meinem calculateur klappt gar rien avec ActiveX - weder dans XProfan 10 encore 11. je dois la fois überprüfen, si mon ComCtl32.ocx qui richtige ist.)

Möglicherweise hängt cela Problem aussi avec cela zusammen, dass lokale Variablen à ActiveX-Funktionen gegeben volonté, qui aussi pour dem sortir de qui Procédure encore aktiv sommes et so soudain sur pas plus gültige Adressen zugreifen. je werde chez Gelegenheit weiterforschen. important ist ici, dass wir une Solution pour cela Problem avons et Uwe Pascals Quellcodes aussi pour XProfan11-Nutzer offen stehen.

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
01.07.2008  
 




Frank
Abbing
si cela Problem seulement lokale Variablen betrifft et pas qui Globalen, peux je avec cela durchaus vivre. Dass lokale Variablen chez erneutem Aufruf einer Prozedure gelöscht volonté, ist oui durchaus gängige Praxis. So suis je es aussi de Assembler aus gewohnt.
 
01.07.2008  
 




Uwe
''Pascal''
Niemeier
allô gens!


Möglicherweise hängt cela Problem aussi avec cela zusammen, dass lokale Variablen à ActiveX-Funktionen gegeben volonté, qui aussi pour dem sortir de qui Procédure encore aktiv sommes et so soudain sur pas plus gültige Adressen zugreifen.


cela pourrait mais seulement sur IUnknown& zutreffen, quoi mais anscheinend pas qui le cas ist.
qui Werte pour/de Control& et Object& (bistrot) volonté direct zugewiesen ; es volonté aucun Pointer verwendet.
Folglich peux aussi ne...aucune späterer Zugriff puis avoir lieu.
à cause de QueryInterface() doit je la fois regarder...


important ist ici, dass wir une Solution pour cela Problem avons et Uwe Pascals Quellcodes aussi pour XProfan11-Nutzer offen stehen.


Mir ging es oui aussi tout autor, qui Routinen possible large abwärtskompatibel trop tenir, tout autor habe je sur OOP verzichtet.
Ist mais déjà pour OCX-Package Version 3 vorgemerkt.
Wäre mais quand même bien, cet Problem jusqu'à dahin geklärt trop avons. qui Übergabe de Pointern, um Variablen trop füllen sollte oui - trotz OOP - durchaus pas ungewöhnlich son.

PS: qui Schwierigkeiten avec SP3 werde je mir bientôt vornehmen.

SeeYou
Pascal
 
02.07.2008  
 




RGH
allô Pascal,

qui Übergabe de Pointern, um Variablen trop füllen, ist - comment Rolf oui aussi déjà festgestellt hat - pas cela eigentliche Problem.
cela Problem vermute je plan dans dem Bereich, wohin Adressen lokaler Variablen à Funktionen transfert volonté, qui aussi pour Beendigung qui aufrufenden Procédure (et dem Ungültigwerden plan cette Adressen) encore weiterlaufen. Hierzu zählen offensichtlich ActiveX-Objekte. sur Anhieb peux je dans Deinem Code zwar aucun derartigen Aufrufe avec Adressen lokaler Variablen erkennen, mais ActiveX hat là möglicherweise Eigenheiten, qui mir encore pas geläufig sommes.
là je momentan sur meinem Entwicklungsrechner qui Beispiele pas la fois sous XProfan 10 zum courir bekomme, doit je une weitere Analyse sur qui Zeit pour dem Release de XProfan 11 Déplacer. (là werde je meinem calculateur un nouveau Motherboard avec besserem Prozessor gönnen. avant dem Release gilt entier streng: Never Change A Running System.) et sollte je wirklich ensuite feststellen, dass je dans XProfan quoi 1faire peux, spricht oui rien vers un kostenloses Update sur un XProfan 11.0a ou bien gar 11.1.

si es aucun wirklichen ShowStopper plus gibt, wird XProfan 11 bientôt festgeklopft et enfin à JDS geliefert. je suis eh déjà (teils par berufliche et private Auslastung, teils par Maßlosigkeit beim Einbau neuer Features) etwa 2 Monate derrière meinem original Zeitplan.

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
02.07.2008  
 




RGH
allô Pascal,
j'ai es pas laisser peut et mon Frühstückspause am Arbeitsplatzrechner geopfert:

qui dessus gepostete Code scheint pas 100%ig stabil trop son. si je cela Déclarer dans qui Procédure CallMethod um plus que trois Variablen erweitere, bricht cela Programme avec einer Fehlermerldung ab. très befremdlich, cela! alors habe je quelque chose plus experimerntiert.

Es xcheint réellement avec dem QueryInterface zusammenzuhängen. j'ai la fois geschaut, quoi je dans XProfan beim HTML-Fenêtre anders fais: là je oui seulement cela Contrôle zurückgebe, fais je chaque fois un nouveau QueryInterface, à Objektadresse trop ermitteln (et naturellement pour Gebrauch des Objektes un Releasen). cela habe je la fois dans Deinem OCX.INC mise en œuvre. Zunächst un ocxCreateC() (cela C steht pour Contrôle):
KompilierenMarqueSéparation
proc ocxCreateC ----------------------------------ocxCreate-------------------------------

    parameters ProgID$,Wnd&,xa%,ya%,xb%,yb%
    return control(AtlAxWin,ProgID$,$50000000,xa%,ya%,xb%,yb%,Wnd&,0,0,0)
    endproc ---------------------------------------------------------------------------------

ensuite qui Proceduren ocxGet, ocxPut et ocxMethod comme ocGetC, ocxPutC et ocxMethodC kopiert et entsprechend erweitert. comme Beispiel ici ocxGetC():
KompilierenMarqueSéparation
proc ocxGetC-------------------------------------ocxGet----------------------------------

    parameters Control&,nom$
    declare Object&,IUnknown&
    declare DispID&,v&,v$
    ~AtlAxGetControl(Control&,addr(IUnknown&))
    Object&=QueryInterface(IUnknown&,~IID_IDispatch)
    clear Var#,Disp#,IID#
    nom$=MultiToWideEx(nom$)
    v&=addr(nom$)--GetIDsOfNames braucht Pointer sur Pointer
    CallMethod(Object&,5,IID#,addr(v&),1,0,addr(DispID&))--GetIDsOfNames
    CallMethod(Object&,6,DispID&,IID#,0,~DISPATCH_PROPERTYGET,Disp#,Var#,0,0)--Invoke

    si Var#.vt%=~VT_BSTR------OLE-String

        v$=WideToMultiEx(Var#.Val&)
        d'autre----------------------numerischer Wert
        v$=str$(Var#.Val&)

    endif

    ~VariantClear(Var#)
    CallMethod(IUnknown&,~Release)
    return v$
    endproc---------------------------------------------------------------------------------

ocxQueryInterface habe je so gelassen, comment dessus posté (avec IFace2#). et déjà klappt alles (zumindest ici am Arbeitsplatz ;) )

seulement ne vague Theorie, ou bien besser Hypothese: Vermutlich peux sich cela ActiveX-objet im grenier Déplacer, quoi mais chez qui statischen Gestion de la mémoire dans XProfan 10 chez den Beispielprogrammen pas vorkam, là là oui nirgendwo neuer grenier angefordert wurde. maintenant ermittle je sur QueryInterface qui Objektadresse (Object&) chaque fois récente et cela Problem scheint behoben.

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
02.07.2008  
 




Uwe
''Pascal''
Niemeier
allô Roland!


seulement ne vague Theorie, ou bien besser Hypothese: Vermutlich peux sich cela ActiveX-objet im grenier Déplacer, quoi mais chez qui statischen Gestion de la mémoire dans XProfan 10 chez den Beispielprogrammen pas vorkam, là là oui nirgendwo neuer grenier angefordert wurde.


Klingt gewagt...
chez qui Entwicklung qui OCX-Routinen habe je aucun Hinweise sur so un Verhalten trouvé.
Allerdings wird chez Programmiersprachen avec ActiveX-Unterstützung oui so assez alles comme bien sûr vorausgesetzt (quoi qui Umsetzung pour Profan oui so schwer pouvoir).
Möglicherweise volonté là qui Pointer automatisch nachgeführt ou bien so.

Werde mich nochmal dahinterklemmen, si es à qui Zeit ist.


si es aucun wirklichen ShowStopper plus gibt, wird XProfan 11 bientôt festgeklopft et enfin à JDS geliefert.


Hat sur jeden le cas Priorität! si cela jusqu'à octobre klappt, hol ego mir personnelle chez JDS ab (Im Herbst zelten à qui lac ist quoi feines )

et une Workaround avons wir oui eh bien aussi

merci pour qui Mühe!

SeeYou
Pascal
 
05.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.070 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