Da gibt's gar nix sprachlos zu sein 
Ich nutze es aktiv und finde es gut wenn es funktioniert. Du hast viel Arbeit damit gehabt bis jetzt und ein bißchen Hilfe kann da ja nicht schaden!
Bzw. der Übersetzung:
Du nutzt doch _Get_lang, das ist doch easy. Ich mach dir, wenn ich Zeit hab, einfach ne Fassung der dbug.au3 mit Umsetzungen auf _get_lang ab str820. Dann schick ich dir den Kram, so daß du den nur noch an die Language Dateien anfügen musst. Ok?
Schlaflos war ich schon, aber nicht wegen deiner Bitte! Ich bin eine fürchterliche Nachteule. Wird's dunkel, kann ich denken und werde kreativ, von daher der beste Zeitpunkt zum debuggen ;-))
Nimm mal die angehängte hier. Ich hab noch ein bißchen am Scrolling getunt ($SCI_ENSUREVISIBLEENFORCEPOLICY). Dann ist es angenehmer beim Hin- und Herspringen, aber wem erzähl ich das ;-)). Und außerdem hab ich noch eine Prüfung eingebaut, ob jemand versucht, bei einer Kommentarzeile einen Breakpoint zu setzen - is blöd, weil da rennt das Ding einfach braun drüber weg... das geht jetzt nicht mehr (außer innerhalb von großen #cs...#ce Blöcken, aber da soll halt jeder selber aufpassen )!
Sag mal, was hälste davon, wenn wir dem Debugger zumindest noch ne deutsche Übersetzung spendieren? Dein Sprachsystem ist ja recht klar. Wenn Du mir nen Nummernkreis zusprichst (sagen wir bspw. str1000 - str1050), dann könnte ich bei Lust und Zeit die Strings mal anpacken. Das Teil ist ja jetzt eh soweit integriert, daß es einzeln nicht mehr nutzbar wäre, da kann man jetzt auch mal ordentlich umbauen, was meinste?
Denke, ich hab den Griff gefunden! Na dann teste mal... ;-))
Das einzige, was jetzt noch nicht geht, ist der Tooltip, wenn man mit der Maus über eine Variable fährt. Aber das liegt in _SCIGetCurWord() begraben. Warum der die Mausposition nicht holt, ist mir noch nicht ganz klar, aber vielleicht find ich das ja auch noch raus...
EDIT: Tooltips für Variablen sollten jetzt auch gehen... Gute Nacht ;-)!
[Anhang entfernt - siehe nächste Posts]
Ich hab ne Idee, was das DBUG Problem anbelangt!
Ich versuchs mal zu erklären und mache 2 Beispiele (hierbei gehe ich davon aus, daß ich ein Stück Code habe, das genau 10 Zeilen hat):
a) ich füge die Zeile #include <dbug.au3> eigenhändig in den Code ein -> Editor hat 11 Zeilen
b) DU fügst vor dem Start im Hintergrund in die temporäre Datei deine geänderte Codezeile ein, startest einmal, damit die Debugzeilen erzeugt werden und startest nochmal, damit das Debuggen losgehen kann -> Editor hat aber nur 10 Zeilen!
-> du hast genau 1 Codezeile Differenz durch das Einfügen deines Includes.
Das wird aber nirgendwo im Debugger berücksichtigt, weil die ganze UDF davon ausgeht, daß du auch genau den Code debuggst, den du im Editor vor der Nase hast. Stimmt aber nicht, es ist ja im Hintergbrund eine Zeile dazu gekommen!
-> das Code Array ist um einen zu lang, sämtliche Marker und Zeilenansprünge sind um 1 verkehrt, jeder Markerlesevorgang liefert einen zuviel. Ich bin nicht alles durchgegangen, aber ich denke, damit rechnet er überall falsch und da ja Scintilla selbst die Markerpositionen zurückliefert, die teilweise angesprungen werden, aber der Code im Hintergrund dazu nicht mehr passt, läuft das auch nicht sauber.
Ich schau mal, ob da irgendwo ein +1 schon ausreicht ;-))
EDIT: Also ich hab grad nen Monster Knoten im Schädel 
und krieg das mit der einen Zeile nicht gewechselt. Mache mich evtl. morgen nochmal dran... 
EDIT 2: Das läßt mir keine Ruhe... ich glaube aber, da sich der genaze Kram teilweise rekursiv wieder aufruft, dürfte die Lösung nicht ganz trivial sein...
Zum Makro...
Folgendes Programm starten: den iss Compiler
Parameter: %projectdir%\Iss Setup Datei.iss <--- da hab ich mehrere Varianten versucht, also auch mit den echten Pfadbezeichnungen usw.
Zum DBUG-Tool...
Ich kann mich gerne versuchen, hab's auch schon probiert, aber ich raff überhaupt nicht, wieso das Ding, als normale include eingebunden, perfekt funzt (also bei mir zumindest), mit stimmigen Zeilen, Run To Cursor, Breaktpoints, etc. usw. und deine angepasste Variante nicht! Allerdings verstehe ich auch die Korrektur, die du an der $lnr vornimmst nicht wirklich. Ich kann zwar sehen, welche Auswirkungen das hat, wenn ich das auf den Originalcode rückändere, und verstehe auch, was du vorhattest, aber ich kapier nicht, WIESO das ÜBERHAUPT nötig ist! Sprich, wieso hast du quasi mit deiner Version andere Zeilennummern, als ich in der "fast" Originalversion... Grrrr.... Momentan hab ich nicht sooo viel Zeit zu suchen, aber ich bleib dran!
Lieber Gruß und nix zu danken!
Holger
Hallo ISI360,
bin ja fast wunschlos zufrieden ;-), aber wäre es möglich, daß die Pfadvariablen für die Makro Dateioperationen (%projectdir%, %scriptdir%,...) auch bei anderen Makrotypen gültig sind?
Ich hab bspw. im Projektordner neben dem Autoitkrams auch z. B. ein Installscript von Inno Setup. Da wollte ich mir ein Makro einrichten, daß ich nachdem Kompilieren direkt den Installer erzeugen lassen kann. Leider komme ich nicht an das Installerscript, da ich Leerzeichen im Projektpfad habe, der Innosetup Compiler erwartet daher den Pfad in Anführungszeichen, aber immer, wenn ich im "Programm ausführen" Makro bei Parameter den Pfad in Anführungsstriche setze, haut mir ISN diese beim Speichern wieder raus. Daher dachte ich, ich könnts über die Variablen lösen, aber das geht auch nicht....
Gruß
Holger
Hey ISI360, nur ne kurze Rückmeldung. Klappt alles hervorragend Danke für die Änder- und Neuerungen!
misterspeed:
Das sind wirklich viele gute Ideen bei. Als Übergangslösung bzgl. des Profilings könntest du dir als Makro ja eine Verknüpfung zu AU3Profiler machen. Dann kannst du ihn immerhin aus dem Menü starten.
AU3Profiler: http://www.autoitscript.com/forum/topic/106811-au3profiler/
Hallo ISI360,
ich hab ne Frage. Wenn ich Opt("MustDeclareVars", 1) in den Quellcode setze, dann bekomme ich mit allen Variablen, die in den Formularen gesetzt werden, Probleme. Sprich Autoit nöselt rum, daß ich das nicht definiert hätte. Wäre es möglich, daß du einen Einstellungsparameter schaffst, der entscheidet, ob bei der Formgenerierung ein "Global" oder "Local" vor die Definition gesetzt wird? Ich meine jetzt nicht den Extracode, da muß ich halt selber aufpassen, nur vor die Formularelemente...
Gruß
Holger
Dietmar:
Wenn du im Menü "Tools" den Punkt "Autoit3Wrapper GUI" benutzt, dann sollten deine gewählten Einstellungen ganz oben ins Script eingefügt werden und beim nächsten Mal Öffnen der Wrapper GUI wieder zur Verfügung stehen. Tut es jedenfalls bei mir so. Wenn Du dann kompilierst, sollte das auch mit einbezogen werden!
Direkt im ISN. Windows XP SP3. Ach so, und mir ist aufgefallen, daß das Funktionen-Auf- und Eingeklappe noch ne kleine Macke hat. Wenn ich alle Funcs zuklappe, speichere, ISN schließe und wieder öffne, find ich nicht den gleichen Zustand wieder.
Gerngeschehen! Mir macht dein Studio eben Spass und den Debugger fand ich wirklich cool Man muss bei dem Debugger nur bedenken, dass er ja auch komplett in Autoit läuft, d.h. wenn viele Events abgeprüft werden, die ständig an der Oberfläche rumschrauben, sobald man nur die Maus bewegt, dann verlangsamt es das Debuggen natürlich etwas. Aber ich denke, das ist zu verschmerzen.
Extrem cool ist, dass es eine Art Konsole gibt, auf der man nicht nur die AutoIt eigenen Befehle abfeuern, sondern auch die eigenen Funcs direkt aufrufen kann. Echt schick...
EDIT:
Sag mal, manchmal verstehe ich das Studio nicht so ganz, was es da treibt. In 85% aller Fälle, wenn ich ein Projekt öffne, benimmt es sich ganz normal. In den restlichen 15% hab ich das Gefühl, als würde es bei jedem Tastendruck nen Screen Redraw machen und blinkt wie wild rum. Is etwas nervig. Hast du irgendeine Idee, womit das zu tun haben könnte?
Hey ISI360,
beim Lesen der ganzen Posts hier ist mir noch eine Frage aufgefallen, die ich gut fand, vielleicht hab ich da nen Vorschlag: da hat jemand nach einem Debugger gefragt. Dafür hätte ich folgende Idee.
Folgendes Debugger Projekt läuft generell ganz gut, wie ich finde: http://www.autoitscript.com/forum/topic/10…ger-for-autoit/, es braucht aber ein paar kleine Anpassungen, damit es sauber mit ISN Autoit Studio läuft
dann kann man diesen Debugger schon ganz gut in ISN Studio nutzen, inkl. Vorlauf bis Zeile x, Markierungen im Editor, wo man gerade ist, bekommt Breakpoints, die wie kleine rote Bomben aussehen 
, etc. usw.
ISI360, was denkst du? Wär das ne Integration wert? Ich fand das Teil zumindest sehr hilfreich in puncto Einzelschrittdebug und Variablenwerte gucken und so. Mit dem passenden Menüpunkt im Studio könnte das ne sehr charmante neue Funktion sein. Der Menüpunkt müßte dann eigentlich nur in die allererste Scriptzeile ein #include setzen und F5 drücken 
Ok, kann man alles selber machen, aber integriert wär doch cool, oder?
Gruß
Formstudio macht da definitiv nichts falsch. Das habe ich überprüft. Ach was solls, wir sich irgendwie lösen lassen... Jetzt bin ich ersma raus, morgen geht's weiter ;-)) Dir noch nen schönen Abend!
MOMENT! Ich konnts nicht lassen und hab jetzt doch weitergesucht bei dem Problem der Beschriftung. Weißt du zufüllig, wie das intern mit den Control IDs funktioniert?
Viele Beschriftungen sind nämlich völlig, aber einige würfelt er über unterschiedliche Forms verteilt - ungeachtet von ihrer Funktion, der jeweilige Button macht immer das was er soll. Kann das sein, daß in unterschiedlichen Forms die gleichen internen Handles vergeben werden und das AutoIt bei der -1 in GUICtrlSetData(-1 evtl. einfach durcheinander kommt?
Mann, ich bin soo auf deine Erweiterung gespannt, damit könnte der Spuk ein Ende haben. Dieses GUICtrlSetData(-1,.... Gelumpe ist mir irgendwie eh nicht geheuer...
Ja habs auch schon fast fertig...funktioniert ganz gut
-> Wird auch für Tabseiten funktionieren
Da bleibt mir außer sprachloser Freude nicht viel zu sagen 
ok klingt echt komisch. Ist der Button durch ein Handle deklariert? Vlt gibt es durch dein Hauptskript wo überschneidungen durch ein Handle das gleich benannt ist oder so...
Ich meins überhaupt nicht böse, aber gib dir keine Mühe ! Ich hab schon alles durch... Als ich "Pillemann" auf den Button geschrieben habe, war das korrekterweise NUR inder zugerhörigen isf zu finden und er hat trotzdem was anderes auf den Button geknallt. Das hat überhaupt nichts mit dem Script oder dem Studio zu tun, sondern MUSS irgendwo im Windows-Wunderland stecken...
Ich nehm es jetzt einfach als Memory Caching/Paging/Wasweißich Voodoo in die Liste der Microsoft Wunder auf und fertig!
Ah gut, das klingt doch absolut stimmig! Dann kann man wirklich mit der Beschriftung treiben was man will. Ich finds Klasse ;-)!
Und zum anderen Problem:
Das man die isf mit nem Texteditor öffnen kann, hab ich ja schon durchexerziert. Dadurch konnte ich ich ja auch feststellen, daß das Studio selber und auch das Formstudio alles richtig gemacht hat und es eben überhaupt keinen Anhaltspunkt im Quellcode gibt, der begründen könnte, warum das passiert! Ich sag, es ist völlig voodoomäßig, was da passiert...
Ich such mal weiter, wenn ich was rausfinde, geb ich Bescheid!
EDIT: Zu deinem EDIT: dann kann ich mir nur grad nicht vorstellen, wie das genau in das Feld zu schreiben wäre. So bspw.: _Func(__("Beschriftung")) ?
Ich hätte jetzt gesagt: Hintergrundfarbe der Eingabefelder ändern?
Sag mal, was anderes. Ich hab was total Merkwürdiges beobachtet und das beschreib ich mal, hoffe es kommt rüber:
Ich hab gestern zum Test mal die Sprachroutine auf Basis deines Tipps mit GUICtrlSetData(-1,__("blablabl")) in ein paar Buttons eingebaut und damit rumgespielt. Plötzlich hatte ich einen Button, der absolut hartnäckig eine "falsche" Beschriftung erhielt, egal was ich gemacht hab. Ich hab sogar den Extracode wieder raus genommen und "Pillemann" in das Text/Data Feld geschrieben, was auch durch Formstudio korrekt in die zugehörige isf Datei geschrieben wurde, aber sobald ich auf "Projekt testen" geklickt hab, war es so, als hätte ich die Änderung nicht gemacht. Da stand dann wieder der falsche Kram. Ich hatte dann irgendwann keinen Bock mehr und hab es vorhin erst wieder probiert. Nach Reboot wohlgemerkt! Gleicher Effekt. Auffallend war, daß das kompilierte Projekt allerdings diese Merkwürdigkeiten NICHT zeigte. Dann hab ich mir ne Routine auf WM_COMMAND / $EN_CHANGE registriert, die den Text nochaml auf den Button klatscht und siehe da, auf einmal wurde der Text wieder aktualisiert.
Kann es sein, das Windows irgendwo irgendwas cached im Zusammenhang mit der Ausführung vom Studio selber und das evtl. hervorkramt? Das würde auch erklären, wieso ewig und drei Tage die Meldung mit der im Hintergrund geänderten Datei kommt und dann auf einmal nicht mehr (cache wieder freigegeben). Ich mach mir da echt keinen Reim drauf....
Das sieht total gut aus! Gilt das dann für Text/Data und Tooltip gleichermaßen? Wäre jetzt, zumindest für mich, logisch...
Und zu deinem Vorschlag:
Ja es wäre durchaus möglich jedoch müsste ich deim Testen der Form die ganzen funcs wieder rausfiltern da das Skript sonst nicht starten würde. (Da wird ja nur die GUI aleine gestartet. Ohne das Hauptskript)
Naja mal sehen was sich machen lässt...
Nee Moment, mach Dir nicht soviel Arbeit! Mach einfach nen Meldefenster, daß man für Tests als Extracode der GUI die Lib includen muss und fertig! Soviel Programmierer wird derjenige, der die Funktion nutzt, wohl sein, um darauf achten zu können. Anfänger nutzen Internationalisierungsroutinen wahrscheinlich eher weniger, oder? Oder knall beim Testen die Funcs in "" und fertig. Dann sieht der Text zwar nicht so schön aus, aber man sieht direkt, ob man noch irgendwo ne Func vergessen hat.
