| |
|
|
Uwe ''Pascal'' Niemeier | allô gens, allô Roland!
cette kleine Code verursacht comme prc ou bien exe chez mir (XP) une Programmabsturz: KompilierenMarqueSéparation!
window 50,50-400,400
declare Edit&
Edit&=create("RichEdit",%hwnd,"Test",10,50,100,100)
RTF("SaveText",Edit&,"Test.txt")
waitke Gibts là irgendwo une grenier-Überlauf ou bien so? par insérer de Leerzeilen (!) avant dem Kompilieren klappts nämlich quelquefois. avec call(&OpenText... gibt es aucun Probleme. Scheint allerdings déjà depuis Profan 7.9 so trop son... je glaub, cela wurde Schonmal angemahnt
SeeYou Pascal |
|
|
| |
|
|
|
| Hm chez mir funktionierts sans Absturz comme interpeter prc et exe, X10RC6 & XPHome. |
|
|
| |
|
|
|
| wohin Leerzeilen? chez mir stützt es aussi ab: Windows98 SE |
|
|
| |
|
|
|
| Dossier wird sans Probleme gespeichert - le contenu: cela mot Text |
|
|
| |
|
|
|
| cela hängt vom jeweilgen System ab et si là justement qui nachfolgende virtuelle grenier realem grenier zugeordnet wurde ou bien pas => scheint un Speicherüberlauf trop son .
je hab mir den faute la fois avec TNT angesehen. qui Adresse avant qui Adresse ist encore zugewiesen et contient données. |
|
|
| |
|
|
|
RGH | enfin la fois un Beispielcode avec diesem ominösen RTF-Bug, qui aussi chez mir abstürzt ... et seulement wenige Stunden später (j'étais déjà am Aufgeben ...), konnte je cette Bug enfin dingfest faire! à einer Stelle wurde chez RTF() un Speicherzugriff gemacht, qui pas son sollte. et je après que, dans welchem Zustand sich qui calculateur justement est, ca va dans qui Hose ou bien plan pas. So J'ai eu den effet, qui es seulement knallte, si je avant dem Compilieren et Starten gefragt wurde, si je Sauver veux et si qui Text im Richedit größer comme deux marque était.
bof, maintenant ist zwar qui soir presque rum, mais cet Problem ist eh bien aussi 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 | 25.09.2006 ▲ |
|
|
|
|
| Moin...
Comme je le disais, hängt avec cela zusammen, si qui grenier sur den là zugegriffen volonté soll, zugewiesen ou non. si qui zugewiesen ou non, hängt u.a. de den Umgebungsvariablen (z.B. Pfad) des Programmes ab. aussi auparavant abgelaufene (grenier-)operationen im Programme spielen là avec rein. un très mieser faute, là dans qui règle cela Programme pas abstürzt et seulement données im grenier überschrieben volonté. j'ai depuis etwa trois Jahren den impression, cela là irgendwo encore so quelque chose dans qui Art rumfleucht... |
|
|
| |
|
|
|
RGH | [quote-part:7b2a2cf450=Andreas Hötker]un très mieser faute, là dans qui règle cela Programme pas abstürzt et seulement données im grenier überschrieben volonté. j'ai depuis etwa trois Jahren den impression, cela là irgendwo encore so quelque chose dans qui Art rumfleucht... [/quote-part:7b2a2cf450] comment je bereits avant ca 15 Stunden schrieb: qui faute ist trouvé et définitif dans XProfan 10 behoben! son braucht Euch alors aucun Gedanken plus tout autor trop faire, sonder simple sur qui prochain Version attendre! ;)
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 | 26.09.2006 ▲ |
|
|
|
|
| allô Roland...
Ist bien sûr, cela meinte je pas . j'ai depuis etwa trois Jahren un Problem, cela sich eigentlich entier ähnlich äußert - avec cette Funktion et speziell avec diesem Problem mais rien trop 1faire hat!
depuis mon Voir le texte source qui 12000 Zeilen überschritten hat , wird zeitweise une très kritische API pas richtig fonctionnement. si qui faute auftritt ou bien pas hängt u.a. en ab, quelle Bedienungsschritte qui User auparavant unternommen hat, comment grand qui Voir le texte source zur Zeit ist, sur welchem calculateur cela Programme fonctionne et si es compilé ou non. je voudrais pas absolument behaupten, qui qui faute à Profan liegt - je voudrais toi mais bitten, es peut-être irgendwo im Hinterkopf trop behalten, cela cela so son pourrait.
´Gruß
Andreas |
|
|
| |
|
|