XProfan

RGH

Dieter Zornow

Dann poste pero por favor veces una möglichst kleines Ejemplo, así Yo el nachvollziehen kann.

Saludo
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

Yo habe dir algo por E-Mail geschickt, como Incluye y propio Encabezamiento verwendet voluntad. El Beispiele müssten aber auch hier en el Foro descargable ser bajo 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

¡Hola, Yo glaube Yo el Ursache gefunden. Offensichtlich macht se Pascal el no dokumentierte (y somit no garantierte) statische Speicherverwaltung de XProfan a einschließlich Versión 10 a Nutze. Als Ejemplo nutze Soy un gekürzten Ver código fuente de su Feder. Bis XProfan 10 funktioniert folgender Ver código fuente:
Kompilieren Marca Separación

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>)

Der Ver código fuente funktioniert natürlich sólo bajo el Annahme, dass el Speicheradresse el Variables Object& y Control& unveränderlich es, qué a XProfan 10 auch zufällig así war. XProfan 11 zeigt hier mehr Dynamik, así el folgende kleine Änderung notwendig se:
Kompilieren Marca Separación

window 100,10-500,500
usermessages 16
 $H Windows.ph
 $H OCX.ph
 $I OCX.inc
declarar ATL&,Var#,Disp#,IID#
ocxInit()
declarar Object&,Control&
declarar c#, o#
dim c#,4
dim o#,4
ocxCreate(MSCAL.Calendar.7,%hwnd,10,100,350,250,o#,c#)
Object& = Largo(O#,0)
Control& = Largo(C#,0)
ocxMethod(Object&,Today)
numwidth 3

mientras que 1

    locate 0,0
    imprimir Tag   ,ocxGet(Object&,Day)
    imprimir Monat ,ocxGet(Object&,Month)
    imprimir Jahr  ,ocxGet(Object&,Year)
    waitinput
    caso %umessage=16:romper

endwhile

ocxMethod(Object&,AboutBox)
destroywindow(Control&)
ocxDeInit()

Mach beachte el Bereichsvariablen O# y C#, en el Ergebnis de ocxCreate() abzuholen. Und ya funktioniert lo auch bajo XProfan 11. Yo nehme a, dass auch el otro Beispiele de UwePascal ebenso simplemente anzupassen son.

Saludo
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

Dieter
Zornow

Ok, danke entonces lo sí bien, Yo hatte sólo veces una bischen rum experimentiert, entonces stürtze cada Programa de y yo pensamiento, el es una Bug en XProfan 11, así kann mansich irren.

Saludo

Dieter

Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2

Frank
Abbing

Offensichtlich macht se Pascal el no dokumentierte (y somit no garantierte) statische Speicherverwaltung de XProfan a einschließlich Versión 10 a Nutze.

Como es él no allein. Willst du sagen, esta para mich ebenfalls gängige Praxis es inmediatamente no mehr gestattet? Auch no en herkömmlicher API? Ist doch Gang y Gebe en diversen Dll-Características el Zeiger en una LongInt a transferencia.

Sebastian
König

Hola Roland,

Yo finde el neue Comportamiento auch bastante irritierend... Auch si streng genommen stimmt, dass el no explizit dokumentiert war, debería uno se con Blick en otro Idiomas doch darauf verlassen puede, dass el Adresse uno Variables no ändert (zumindest solange ellos gültig es, also en globalen Variables dauerhaft y en lokalen para el Dauer des Procedimiento- o. Funktionsaufrufs). Si el no mehr se da, podría uno algo überspitzt fragen, welchen Sinn Addr() para normale Variables überhaupt todavía hätte...

Natürlich Es el dynamische Adressverwaltung en el otro Página una feine Sache - kannst Usted lo tal vez así einrichten, dass Variables, deren Adresse se determina, antes una Verschieben en el Speicher geschützt voluntad?

MfG

Sebastian

Windows XP, XProfan/Profan² 4.5 bis 11
Profan2Cpp-Homepage: [...]

Alte Profan²-Seite: [...]

RGH

¡Hola!

Zunächst una vez: El Übergabe uno Wertes en Adresse uno Variables a una API-Función es grundsätzlich kein Problema. Problemas puede offensichtlich sólo entonces en bastante speziellen Fällen auftauchen, si encima esta Adresse Werte zurückgegeben voluntad.

Bislang Tuve para Abspeichern el Variables en Delphi una statisches Array benutzt. Daher war el anzahl el Variables De todos modos beschränkt, como el Array para Programmbeginn producido wurde.
In XProfan 11 verwende Yo el Open Arrays en Delphi y el benutzen offensichtlich una algo otro Speicherverwaltung.

Yo schaue veces, si Yo como en el Schnelle todavía qué drehen kann, voluntad aber nichts versprechen.

Das Problema scheint sí sólo en muy speziellen Fällen aufzutreten. Im Normalfall restos el Adresse uno Variables sí tatsächlich siempre todavía bestehen. Das Problema scheint sí, como lo sólo ahora después de encima una halben Jahr seit el ersten Subscriptionsversion aufgetaucht es, sólo extremo selten aufzutreten. Möglicherweise tatsächlich sólo en Active X.

Saludo
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

Willst du sagen, esta para mich ebenfalls gängige Praxis es inmediatamente no mehr gestattet? Auch no en herkömmlicher API? Ist doch Gang y Gebe en diversen Dll-Características el Zeiger en una LongInt a transferencia.

En herkömmlicher API scheint lo weiterhin keinerlei Problemas a geben. So como después de más Experimenten aussieht, ändert se auch tatsächlich no el Adresse el Variables. Como Yo oben ya erwähnte: Vermutlich tritt el problema sólo en seltenen, bastante speziellen Fällen en.

Saludo
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

Nutzt Delphi como Heaps [...]

RGH

... y ya que aussieht, laufen en mi Rechner a Casa (XP Pro SP3) el Beispiele de Uwe Pascal werder bajo XProfan 10 todavía bajo XProfan 11. Lo kommt siempre el Meldung CallMethod - Unbekannter Name. (Sí, Yo el ComCtl32.ocx registriert ....) In el Firma (XP Pro SP2 ha lo geklappt.)

Dann muß Yo mich wohl doch otro Temas zuwenden ...

Saludo
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

Uwe
''Pascal''
Niemeier

¡Hola Personas!

Zunächst veces: Yo habe en el Moment weder XP SP3 todavía XProfan 11 disponible, por lo tanto kann ego no incluso testen.

Aber: El de Roland reklamierten Variables haben en dieser Versión el OCX-Routinen direkt nichts con el ActiveX-Características a tun:
Kompilieren Marca Separación

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&)

El beiden Pointer kommen en el Proc como ObjAddr& y CtrlAddr& a, Object& y Control& voluntad lokal otra vez deklariert y al Ende el Proc voluntad el - como Parámetro übergebenen - Pointer con LONG gefüllt.

Das Problema podría also auch en el direkten Übergabe de
addr(Variable&) como Parámetro para una Procedimiento mentira oder en el lokalen Deklaration uno global ya vorhandenen Variable...

PS: Im Ejemplo se Versión 1 el OCX-Routinen verwendet. Como sieht lo porque con Versión 2 de?

SeeYou
Pascal

01.07.2008 ▲