XProfan

- 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:
Kompilieren Marque Sé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

- 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:
Kompilieren Marque Sé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:
Kompilieren Marque Sé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()):
Kompilieren Marque Sé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:
Kompilieren Marque Sé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

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

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:
Kompilieren Marque Sé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: [...]

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

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.

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):
Kompilieren Marque Sé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():
Kompilieren Marque Sé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 ▲