| |
| |
|
Uwe
''Pascal''
Niemeier | allô Roland!
qui faute, chez dem qui Adressen de Variablen par Proc-Aufrufe déménagé volonté, ist dans qui aktuellen Version 11.2ß toujours vorhanden 
il hat sich bloß quelque chose pour hinten verschoben; veux dire: Tritt seulement ab einer gewissen Parameterzahl sur.
QED:
KompilierenMarqueSéparationwindow 500,400
proc Demo-------------------------------------------------------------
parameters x1&,x2&,x3&,x4&,x5&,x6&--Ohne Parameters klappt es
endproc---------------------------------------------------------------
declare Wert&,Test&--bei Weglassen der 2. Deklaration klappt es
print Addr 1 ,addr(Wert&)
Demo(1,2,3,4,5,6)
print Addr 2 ,addr(Wert&)
wai
Zwar ließen sich peut-être Workarounds pour cela Problem finden; quand même pourrait/sollte es doch so pas son?
BTW: Offensichtlich sommes mon OCX-Routinen c'est pourquoi toujours pas funktionsfähig
Zur Erinnerung: Selbige ermöglichen u.A. qui Nutzung des champ d'application de commandement aller gängigen Scriptsprachen (JS, VBS, VBA, WSH) sous XProfan; tout autor liegt mir soviel daran. (et weil vous de mir sommes  )
Hoffe sur (baldige) Aider
Pascal |
|
| |
| |
| |
|
|
 | je hatte es so verstanden, dass weil es ne...aucune Bug ist rien daran geändert wird.
aussi à cause de qui Desktopsymbole chez Roland [...]  habe je un Brett avant Augen, si es daran liegt. |
|
| |
| |
| |
|
|
RGH | Salut,
un entier einfacher Workaround scheint trop son, statt LongInt (&) sur Integer (%) umzusteigen. là beide im 32-Bit-Programme juste grand sommes, pouvoir cela keinen Unterschied. si je cela droite vois, tritt cela Problem seulement chez LongInts sur. je schaue mais naturellement, si je cela gefixt bekomme, aussi si es pour qui normale Verwendung de Variablen aucun rôle écoutes.
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 | 04.04.2009 ▲ |
|
| |
|
|
Uwe
''Pascal''
Niemeier | Hi iF!
je hatte es so verstanden, dass weil es ne...aucune Bug ist rien daran geändert wird.
si qui Adresse einer globalen Variablen sich par une Procédure-Aufruf (à dem qui Variable pas la fois selbst beteiligt ist) ändert et ca sous pas näher bekannten Bedingungen (dépendant de vorherigen Deklarationen, Parameterzahl qui Proc, Art qui Auswertung qui paramètre usw) , ensuite ist cela IMHO définitif un Bug.
car: quoi nützt @Addr(), si le Rückgabe un paire Programmzeilen plus ungültig ist, weil zwischendurch une Procédure aufgerufen wurde?
Aussi ist cet Art qui Verwendung de Pointern sowohl chez Windows selbst comme aussi chez anderen Programmiersprachen couloir et Gäbe..
espérer wir alors cela Beste...
PS: Mir brennt dans Sachen HTML aussi qui Zeit sous den Nägeln; si je réellement irgendeinen Workaround bricoler doit, lasse je es toi savons!
SeeYou
Pascal
Nachtrag @Roland: était wieder la fois trop lente beim écrivons! 
merci pour den Tipp! Wird tout de suite getestet! |
|
| |
| |
| |
|
|
| un Workaround ist Reboos ProAx, geladen avec einem z.B. 8x1 Pixel Flashfilm sur einem DC qui abgepixelt wird wobei qui Flashfilm arrêt 8 Bit Montrer peux comme Kommunikationskanal. qui Flashfilm wiederum peux js auslösen et wiederum avec dem body kommunizieren.
s'il te plaît pas rire, cela funktioniert et je pourrait cela chez besoin herauskrahmen.
toutefois empfand je cet Solution comme unentsprechend... (et lente...) |
|
| |
| |
| |
|
|
RGH | Salut,
vergiß meinen Workaround. cela Problem tritt aussi chez Integers sur.
je fürchte, cela peut sich aussi à peine changement. Zur Speicherung qui Variablen benutze je qui dynamischen Arrays de Delphi. là gibt es pour jeden Variablentyp un Array. Wird eh bien une neue Variable deklariert wird qui Taille des Arrays um 1 ertweitert (Delphi: SetLength(IntVar, IntNr + 1)) et ensuite nom et Wert dans cela Array geschrieben. Wird cela Array eh bien größer, bleibt es alors pas aus, dass irgendwann qui Speicherbereich pour cela Array à une autre Stelle déménagé volonté muss, wohin plan cette zusätzliche place ist. comment cela Delphi ou bien Windows interne handhabt, sais je naturellement pas.
avant qui Dynamisierung trat cet Problem plan c'est pourquoi pas sur, là là qui grenier pour alle möglichen Variablen juste trop Programmbeginn reserviert wurde.
cela est dans qui aktuellen Praxis: une Variablenadresse ist mindestens so longtemps gültig, jusqu'à une weitere Variable cette Typs deklariert wird (par Déclarer, Var ou bien Paramètres).
je fürchte, à diesem Verhalten peux je vorerst aussi rien changement. (Es sei car, quelqu'un hat une allumage concept.)
Salut
Roland
Nachtrag: peux Du pas Bereiche verwenden? qui Adresse eines Bereiches sollte sich pas Déplacer, là ici im entsprechenden Array oui seulement un aiguille sur den Bereich steht. Statt einer Lonint-Variablen alors un 4 Byte großer Bereich. |
|
| |
| 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 | 04.04.2009 ▲ |
|
| |
|
|
RGH | cela klappt chez mir:
KompilierenMarqueSéparationwindow 500,400
proc Demo-------------------------------------------------------------
parameters x1#, x2#, x3#,x4#, x5#, x6#
print x1#, x2#
endproc---------------------------------------------------------------
declare wert#, test#
dim wert#, 2
dim test#, 2
print Addr 1 ,addr(Wert#)
Demo(wert#,wert#,wert#,wert#,wert#,wert#)
print Addr 2 ,addr(Wert#)
put
|
|
| |
| 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 | 04.04.2009 ▲ |
|
| |
|
|
| @Pascal: je comprends toi déjà mais cela trifft arrêt seulement sur (echte) Variablen trop qui plan pas gemanaged sommes.
@RGH: aussi si Du cela la fois avant et derrière einer grösseren Anwendung einbaust dans qui einiges passiert?
j'ai aucun allumage concept. (quoique je Schonmal dachte une gehabt trop avons, la fois drüber grübeln...)
Ah, je weiss wieder comment... la fois zurechtschreiben - ist ne Präkompiler-Solution avec dem le tort cela pour den Zugriff qui Werte arrêt ne Sonderfunktion notwendig ist. (Umgekehrter le tort) |
|
| |
| |
| |
|
|
RGH | iF
@RGH: aussi si Du cela la fois avant et derrière einer grösseren Anwendung einbaust dans qui einiges passiert?
oui, qui Bereiche rester à ihrem place! (Bien sûr seulement jusque einem erneuten DIM. ;) )
Sonst würden vous oui pas du tout marcher.
qui entsprechende Umbau sollte sich pour Pascal dans Grenzen tenir.
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 | 04.04.2009 ▲ |
|
| |
|
|
| Nachtrag:
à meinem Beispiel, serait je statt pour reguläre Longs:
KompilierenMarqueSéparationlong a,b,c
umgewandelt in
var a&=0
var b&=0
var c&=0
einfach
addr a,b,c
dispose a,b,c
umgewandelt in
var a&=globalAlloc(gPtr,4)
var b&=globalAlloc(gPtr,4)
var c&=globalAlloc(gPtr,4)
hier im programm mit dem wissen
dass sich hinter a& die Adresse
befindet, und nicht der Wert
long(a&,0).
dispose a&,b&,c&
end
verwenden.
Könnte XProfan chez Dispose avec einem GlobalFree réagir? |
|
| |
| |
| |
|
|
Uwe
''Pascal''
Niemeier | Hi gens!
Roland
cela est dans qui aktuellen Praxis: une Variablenadresse ist mindestens so longtemps gültig, jusqu'à une weitere Variable cette Typs deklariert wird (par Déclarer, Var ou bien Paramètres).
Habe je aussi justement festgestellt. avec cela ist @Addr() trop einer vraie unsicheren l'affaire geworden
cela Übergeben eines Variablen-Pointers dient oui dans mon cas seulement en supplément, de einer Proc plus que den direkten Rückgabewert trop erfragen (Zusätzliche Rückgaben wurden plan per Pointer dans qui entsprechenden Variablen geschrieben).
quand même: cet Possibilité sollte früher ou bien später wieder dans irgendeiner forme zur Disposition stehen.
Roland
qui entsprechende Umbau sollte sich pour Pascal dans Grenzen tenir.
Stimmt!
Soweit je meinen eigenen Code durchschaue, diente cela Ganze seulement qui confort des Anwenders, weil qui so sa eigenen Variablen verwenden konnte (ansonsten ist qui concept de iF une Alternative,
quoique a& = a# ensuite oui aussi marcher devrait).
Stattdessen sollte sich une System-Variable einbauen laisser, en le contenu pour Aufruf qui betreffenden Funktion plan umkopiert volonté doit... ou bien quelque chose comme dans qui Art.
Werde la fois voyons, quoi sich faire läßt...
SeeYou
Pascal |
|
| |
| |
| |
|
|
Sebastian
König | alors je trouve, Pascal hat droite. qui avec Addr() ermittelte Adresse sollte sich solange qui Variable gültig ist (chez globalen Variablen alors au cours de qui gesamten Laufzeit) pas changement dürfen. Dass cela dans qui acte trop Problemen mener peux (et obendrein trop gemeinen, so une faute trop lokalisieren ist oui alles autre comme simple...), montrer oui Pascals OCX-Codes.
si qui Ursache dans qui Verwendung qui dynamischen Arrays liegt, ist qui unschöne Konsequenz wohl, dass sich cet zur Speicherung qui Variablen schlicht pas eignen. mon Vorschlag ist donc, qui Verwaltung umzustellen, quoi naturellement wohl pas so kurzfristig possible ist... mais zumindest pour qui prochain Version peut-être déjà.
mon Vermutung wäre, dass qui Arrays interne une Art Vektor-super sommes (womöglich steht cela irgendwo dans qui Delphi-Documentation). Es devrait ensuite doch possible son, qui dynamische Gestion de la mémoire selbst trop implementieren et dabei sur qui de Delphi bereitgestellten Datenstruktur-Klassen zurückzugreifen. So ließe sich avec peut-être garnicht allzu viel travail cela Problem beheben.
MfG
Sebastian
P.S.: encore une concept: Zumindest pour globale Variablen pourrait on peut-être doch kurzfristig quelque chose einrichten, indem on vous beim Kompilieren zählt et festen grenier dans passender Taille bereitstellt. je sais naturellement pas, comment simple une solche Sonderbehandlung einzubauen wäre... |
|
| |
| |
| |
|
(568)
Deutsch
English
Français
Español
Italia