Bas.Edit der Basic Editor unter Windows !

Es gibt 157 Antworten in diesem Thema, welches 86.203 mal aufgerufen wurde. Der letzte Beitrag (28. August 2017 um 12:41) ist von syshack.

  • Tja, da scheint es noch mehr Probleme unter Mono zu geben :(

    Unter Windows ist ein VAL("&h80")=128, das geht wohl unter Mono nicht. Müsste ich also die Hex-Umwandlung anders angehen... (Kleine Randnotiz: ich mochte die &h80-Notation eh noch nie, die 0x080 aber auch nicht, die einzig wahre Form ist doch ein $80!)
    Insgesamt ist das aber wohl ein größerer Angang, dem ich mich dann wohl mit mehr Aufmerksamkeit widmen müsste.

    Als Testmöglichkeit, ob es denn wenigstens danach klappt, müsste man in der Tokenlist alle $xx durch ihre Dezimal-Pendants ersetzen. Aber der Fehler bei ASC() macht mir noch große Sorgen...

    Für abraXxl hier der Source für die ShowOneLine-Routine, an der Stelle mit dem "cNr = Asc(Zeile.Substring(x, 1))" scheint's ihn unter Mono ja zu zerbröseln
    :

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Cool, das Tool wird von Tag zu Tag besser! Danke für deinen Einsatz!! :thumbsup:

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Der Diskmanager kommt Deinem angestrebten Einsatzzweck schon näher, oder? 8)

    Da wollte ich dann irgendwann noch mit den FE3-LOADER-Dateien ansetzen, sowas wie
    1. Programm auf die Disk schieben
    2. Schauen, ob wir dafür schon eine LOADER-Definitionen haben
    3.a falls ja - übernehmen
    3.b falls nein - beim User nachfragen, ob er dafür LOADER-Informationen eingeben möchte (optional: in DB für andere User speichern)
    3.c falls ja - übernehmen
    4. wenn bei 3. was rausgekommen ist, an eine bestehende LOADER-Definition für diese Disk anfügen
    und ganz am Schluss vielleicht noch sowas wie
    5. LOADER-Datei für Disk bearbeiten (Menüpunkte verschieben, umbenennen, löschen etc.), also noch eine LOADER-Manager-Funktion ausgehend vom Diskmanager

    Ist noch nicht ganz ausgegoren in meinem Hirn, aber es es entsteht langsam ein Bild...

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Neue Version 1.32 hochgeladen

    Code
    - Unterstützung für D71 und D81 Diskimages

    Der Typ eines Diskimages wird beim Laden anhand der Dateilänge, beim Erzeugen anhand der Dateiendung bestimmt.
    Also, wenn man z.B. ein D71 Diskimage erzeugen möchte, kann man einfach "Create empty diskimage" anwählen und die Dartei z.B. NeuesImage.D71 nennen.
    Beim Laden schaut BasEdit nach der Dateilänge :

    Code
    Dateilänge   Disktype
    174848     D64 
    349696     D71 
    819200     D81

    Diskimages mit error byte blocks werden nicht erkannt oder geladen!

    Und noch eine Einschränkung für D81 Diskimages: Es werden (noch) keine Partitionen oder Unterverzeichnisse unterstützt!

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Noch ein Nachsatz zu Mono: Hab das gerade mal auf meinem Mac probiert und bin dabei auf folgende Probleme gestoßen:

    1. Pfadprobleme - lassen sich durch Vermeiden von .\ und Beachtung von Groß-/Kleinschreibung lösen
    2. &H80 kann nicht ausgewertet werden - ließe sich durch eine andere Hex-Dez-Routine lösen
    3. Absturz mit Index out of Range nach dem Laden eines PRG - muss genauer untersucht werden
    4. Absturz nach Eingabe einiger Tastenkombinationen mit Shift/Ctrl/Alt
    5. Die Tastaturauswertung funktioniert nicht wirklich, nur ungeshiftete Zeichen werden erkannt, nicht einmal shift-2 für Anführungszeichen gehen

    Und das ist erst der Anfang. So leid es mir für alle Nicht-Windows-User tut, ich lege das erstmal beiseite, um mich weiter um die Funktionalität von BasEdit zu kümmern.

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Wobei ich es etwas merkwürdig finde, dass das nicht automatisch vom System umgesetzt wird zwischen "\" und "/", je nach System. Muss mal schauen, ob man irgendwie den Directory-Separator abfragen kann, den das aktuelle System benutzt.


    Windows sollte auch / verstehen, unter Unix ist dagegen alles ausser / und dem 0-Byte ein gültiges Zeichen im Filenamen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.


  • Noch ein Nachsatz zu Mono: Hab das gerade mal auf meinem Mac probiert und bin dabei auf folgende Probleme gestoßen:
    1. Pfadprobleme - lassen sich durch Vermeiden von .\ und Beachtung von Groß-/Kleinschreibung lösen


    Oder man nutzt wie schon mehrfah erwähnt "/" oder den DiretorySeperator und nur Kleinschreibung.


    2. &H80 kann nicht ausgewertet werden - ließe sich durch eine andere Hex-Dez-Routine lösen


    Also in folgendem Beispielprogram funktioniert die Hexwandlung so wie du sie gemacht hast.


    Nimm mal bei dir ein kleines "h".


    4. Absturz nach Eingabe einiger Tastenkombinationen mit Shift/Ctrl/Alt


    Unter Lucid nicht nachvollzeihbar.


    5. Die Tastaturauswertung funktioniert nicht wirklich, nur ungeshiftete Zeichen werden erkannt, nicht einmal shift-2 für Anführungszeichen gehen


    Unter Lucid nicht nachvollzeihbar.


    Und das ist erst der Anfang. So leid es mir für alle Nicht-Windows-User tut, ich lege das erstmal beiseite, um mich weiter um die Funktionalität von BasEdit zu kümmern.


    Das ist sehr schade. Aus meiner Erfahrung hat man nachher mehr Schmerz damit, etwas rückzuportieren.

    Bisher gute Arbeit weiterso.


  • Für abraXxl hier der Source für die ShowOneLine-Routine, an der Stelle mit dem "cNr = Asc(Zeile.Substring(x, 1))" scheint's ihn unter Mono ja zu zerbröseln

    Meine rudimentären Mono/VB.Net Kenntnisse lassen mich auf ein Of-by-One Problem scliessen. Doch waurm passiert dies unter Windows nicht?

    Schau mal in den Code:

    Hier die Ausgabe aus meinem xterm:

  • Okay, was jetzt folgt ist das was Neudeutsch so schön "rant" heißt, also einfach nur mein Gegrummel. Ich weiß, das gibt bestimmt Mecker, aber ich muss das mal loswerden :)

    <rant>
    Das mit dem DirSeparator hab ich ja schon drin, das bezog sich mehr auf die Groß-/Kleinschreibung.
    An Dateisysteme mit case sensitive filenames kann ich mich nicht gewöhnen - ich fühle mich mit Schlowski genauso angesprochen wie mit schlowski und kann nicht einsehen, dass das zwei unterschiedliche entities sein sollen...

    Das geht dann weiter bei dem VAL("&h80") - warum zum Geier ist denn VAL("&H80") nicht gültig? Und ist dann VAL("&ha0") <> VAL("&hA0")? Oder erzeugt das sogar einen Fehler? Anmerkung: Hab das inzwischen "voll manuell" gelöst, d.h. ohne ein VAL mit irgendwelchen Hex-Werten sondern auf die klassische Art zeichenweiser Umwandlung und Umrechnung. Das funktionierte dann auch unter Mono...
    </rant>

    Das mit der Tastenauswertung ist interessant, da scheint dann nur der Mac-Mono-Port drunter zu leiden. Aber das lässt mich befürchten, dass es neben grundsätzlichen Mono-Inkompatibilitäten auch noch System-spezifische Probleme gibt, das macht das nicht einfacher *grusel*

    Zitat

    Das ist sehr schade. Aus meiner Erfahrung hat man nachher mehr Schmerz damit, etwas rückzuportieren.


    Da gebe ich Dir prinzipiell Recht, aber eigentlich hatte ich nie vor, das auf was anderem als Windows laufen zu haben. Das war ja alles nur, weil ich gefragt wurde, ob das auch woanders läuft. Aber ehrlich gesagt ist mir persönlich das völlig schnurz, auch wenn ich durchaus verstehe, das das für andere total ärgerlich ist. Aber ich muss auch sehen, wie ich meine Prioritäten setze, habe nur eine gewisse Menge an Zeit zur Verfügung, und die möchte ich dann für Features nutzen, die ich selbst für wichtig halte und/oder die mir einfach mehr Spaß machen. Ich möchte damit niemandem auf die Füße treten, aber nachdem ich jetzt einen Abend mit Mono rumprobiert habe und noch nicht einmal die Spitze des Problem-Eisberges erklommen habe, wollte ich lieber wieder was machen, woran ich Spaß habe. Das er bei ASC(...) mit nirgendwelchen UTF8-Umwandlungen abschnasselt hat mir den Rest gegeben...

    Das mit der Portabilität von .NET Programmen dank Mono läuft in etwas genauso gut wie die vielgepriesene Portabilität von C-Programmen. Prinzipiell schon, es sei denn, man versucht das mit einer echten Anwendung :) Dann kommen all die kleinen Tücken und Kinken zum Tragen und die Anpassungen daran dauern nochmal so lange wie die ursprüngliche Programmierzeit... Oder man muss vorher schon wissen, was geht und was nicht und kann das dann gleich berücksichtigen. Aber dazu fehlt mir die Zeit und die Lust, mich erstmal in Mono einzuarbeiten.

    Also: Vielen Dank an alle, die sich die Zeit genommen haben, das zu testen - zumindest wissen wir jetzt, das es nicht geht.

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Meine rudimentären Mono/VB.Net Kenntnisse lassen mich auf ein Of-by-One Problem scliessen. Doch waurm passiert dies unter Windows nicht?

    Code
    For x = EditInfo.OffX To Zeile.Length() - 1

    Das wäre aber sehr merkwürdig, weil meine Schleife nur bis Zeile.Length()-1 geht - die kann da nicht drüberhinaus laufen
    Und der Startwert EditInfo.OffX (das ist der Offset am linken Rand, wenn man rechts über die Fensterbreite rausgelaufen ist und der ganze Quelltext nach rachts scrollt) ist 0 wenn man ein neues PRG lädt. Also so spontan sehe ich nicht, wie ich hier außerhalb der erlaubten Grenzen landen kann...Und wie Du schon sagts - warum passiert das dann unter Windows nicht?
    ich befürchte eher, dass da irgendeine Zeichenumwandlung mit 2-Byte UTF's arbeitet und deswegen das Ganze nicht mehr stimmt. Das war ja auch in einer Fehlermeldung zu ASC(...) zu sehen.

    Code
    ...
    Parameter name: bytes
      at System.Text.UTF8Encoding.InternalGetBytes (System.Char* chars, Int32 count, System.Byte* bytes, Int32 bcount, System.Char& leftOver, Boolean flush) [0x00000] 
      at System.Text.UTF8Encoding.InternalGetBytes (System.Char[] chars, Int32 charIndex, Int32 charCount, System.Byte[] bytes, Int32 byteIndex, System.Char& leftOver, Boolean flush) [0x00000] 
      at System.Text.UTF8Encoding.GetBytes (System.Char[] chars, Int32 charIndex, Int32 charCount, System.Byte[] bytes, Int32 byteIndex) [0x00000] 
      at Microsoft.VisualBasic.Strings.Asc (Char String) [0x00000] 
      at Microsoft.VisualBasic.Strings.Asc (System.String String) [0x00000] 
      at BasEdit.frmMain.ShowOneLine (System.Drawing.Graphics myGraphic, System.String Zeile, Int32 y, Boolean 
    ...

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.


  • Also: Vielen Dank an alle, die sich die Zeit genommen haben, das zu testen - zumindest wissen wir jetzt, das es nicht geht.

    Ich danke trozdem dir und anderen Beteiligten für den Versucht :)

    Mega Drive | Neo Geo AES 3-4 | Apple IIe | C64 ASSY 250407 | A500+ | A1000 (GB-Edition) | A3000D rev.9.01 | A4000D rev.B

  • Neue Version 1.33 hochgeladen:

    Code
    - kleine "Projektverwaltung" eingebaut

    Man kann jetzt im neuen Project-Menü ein Projekt anlegen, laden, speichern und schließen.
    Ein Projekt ist nichts weiter als eine kleine Ansammlung von Pfadangaben :)

    Bitte melde dich an, um dieses Bild zu sehen.

    Project name - Wird bei einem geöffneten Projekt im Menü angezeigt
    Project file - unter diesem Namen wird das Projektfile immer gespeichert
    PRG file - unter diesem Namen wird das PRG-file automatisch gespeichert
    TXT file - unter diesem Namen wird das PETSCII-file automatisch gespeichert
    Basic tokens - zugehörige Token-Datei, wird automatisch beim Projekt laden aktiviert
    ASCII tokenizer - zugehörige ASCII-tokenizer Datei, wird automatisch beim Projekt laden aktiviert

    Beim Speichern werden automatisch die PRG und die TXT-Datei gespeichert, es wird jeweils ausgehend vom aktuellen Editor-Zustand die jeweils andere Datei neu erzeugt.

    Achtung: Wenn ein Projekt geöffnet ist und man z.B. eine andere PRG-Datei über das File-Menü lädt, wird der Projekt-interne Name nicht nicht geändert, das führt beim Projekt-Speichern oder bei F5 zu einem Überschreiben der Projekt-PRG-Datei! Das ist gewollt, um Dateien sozusagen ins Projekt zu importieren.

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Neue Version 1.34 hochgeladen

    Code
    - ' als Kommentar im Label-Modus wird nicht in den Zeilennummern-Modus übernommen
    - neuer Switch in Tokenfiles: HasSimpleRem=0/1
    - Syntax Highlighting bleibt jetzt auch korrekt erhalten, wenn man nach rechts scrollt
    - Projektfile um neue Option erweitert: shorten variables

    Im Projektmodus kann der einfache ' als Kommentar im Label-Modus sozusagen als unsichtbarer Kommentar für das PRG-file benutzt werden. Bei der Umwandlung von Labels in Zeilennummern wird alles nach einem ' einfach ignoriert.
    Also auch sowas wie

    Code
    A=5  ' IRGENDEIN KOMMENTAR


    obwohl das syntaktisch fehlerhaft wäre.
    Ausnahme: Wenn der aktuell gewählte Basic-Befehlssatz ein ' als REM-Ersatz erlaubt, wie z.B. ExBasic Level II. Dafür kann man jetzt im Tokenfile das Setting HasSimpleRem einstellen.

    Auf vielfachen Wunsch Einzelner hab ich mich mal an die Umsetzung der automatischen Variablenkürzung gewagt.
    Da dieser Vorgang den Quelltext nicht unerheblich verändert hab ich das nur im Projekt-Modus erlaubt, außerdem wird das nur bei der Labelmode in Zeilennummern-Umwandlung durchgeführt.

    Gedacht ist es für folgendes Vorgehen:
    1. Neues Projekt anlegen und in den Label-Modus wechseln bzw. bestehendes Projekt öffnen
    2. Nach Herzenslaune Quelltext einhacken, dabei ohne mit der Wimper zu zucken lange Variablennamen benutzen
    3. Irgendwann mal ausprobieren, ob das eigentlich läuft, was man da so zusammenbraut -> F5 und im Emulator testen
    4. Wieder zurück im Editor
    4.a Fehler bereinigen oder Source erweitern - zurück zu 2
    4.b oder alles abspeichern und fertig

    Beim Schritt 3 wird der Quelltext automatisch im Hintergrund wieder in ein Programm mit Zeilennummern übersetzt und dabei werden dann auch die langen Variablennamen auf 2-buchstabige zurückgekürzt.
    Das Vorgehen beim Kürzen ist folgendes:
    1. Variablenliste erstellen (Crossreference ohne Dialog am Ende)
    2. Die Variablenliste alphabetisch absteigend abarbeiten
    3. Falls Variablename länger als 2 Buchstaben bzw. Buchstabe+Ziffer wird gekürzt (z.B. ABER)
    3.a Es wird nacheinander geprüft, ob der Erste + x.Buchstabe des Variablennamens schon als Variable vergeben ist (AB, AE, AR)
    3.b falls so kein geeigneter Variablenname gefunden wird, A0 -ZZ durchtesten
    3.c falls wir immer noch keinen gefunden haben ->PANIK,ERROR (dann sind aber auch schon alle 936 möglichen Variablennamen vergeben...)
    4. Langen Variablennamen im gesamten Quelltext gegen kurzen Variablennamen austauschen
    5. Kurzen Variablennamen in die Liste vergebener Namen aufnehmen
    6. zurück zu 2. bis die Liste abgearbeitet ist

    Meine Tests sahen soweit ok aus, durch es wird immer innerhalb einer Variablen"gruppe" getestet und ersetzt (A, A%, A$, A(), A%(), A$() )
    Durch die alphabetisch absteigende Reihenfolge werden zuerst längere, dann kürzere Variablen (ABER, ABERMALS) getestet, damit es da nicht zu Problemen kommt. Außerdem wird noch der "Kontext" um den Variablennamen herum abgeprüft, damit es beim Ersetzen nicht zu Problemen kommt (BERM, ABERMALS)

    Code
    ab=1
      ac=2
      aber=3
      achtung=4
      ab$="b"
      ae$="e"
      aber$="r"
      abermals$="m"
      print ab,ac,aber,achtung
      print ab$,ae$,aber$,abermals$
    Code
    10 ab=1:ac=2:ae=3:ah=4
    20 ab$="b":ae$="e":a0$="r":ar$="m"
    30 printab,ac,ae,ah
    40 printab$,ae$,a0$,ar$

    Insgesamt war das deutlich anspruchsvoller als ich zuerst dachte...

    Ach ja, und für Rückmeldungen, ob das wirklich funktioniert wäre ich dankbar :)

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Mann, du bist eine Maschine. Werd ich gleich testen!

    Hmm, ich hab Probleme, den Vice aufgerufen zu bekommen, beim Rumspielen ist mir was aufgefallen:

    Das Projekt-Öffnen geht bei mir immer schief, wenn das Projekt nicht im gleichen Ordner wie BasEdit liegt. Der Pfad zu den Tokenfiles wird offenbar relativ zum Arbeitsordner zusammengestellt? Denk dran, dass der Arbeitsordner fast immer nicht das des ausführenden Programmes ist.

    Sonst bin ich noch über Leerzeichen im Dateinamen gestolpert, Abhilfe war, um das %F in der basedit.ini Anführungszeichen zu setzen.
    Das Variablensetzen hat dann problemlos geklappt. Auch ein dickes Plus für das Beibehalten der Variablennamen, die kurz genug sind!

    Wäre eigentlich denkbar, eine Art Zeilennummerstart für die generierten Zeilen einzusetzen? Man könnte quasi einen Spezialcode nehmen, damit beim Autogenerieren der Zeilen ab dem Code die Zeilennummern mit einem wählbaren Wert beginnen? Ist aber nicht wirklich wichtig.

    Grossartige Arbeit!

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Zitat

    Das Projekt-Öffnen geht bei mir immer schief, wenn das Projekt nicht im gleichen Ordner wie BasEdit liegt.


    Ja, das ist mir gestern auch schon aufgefallen, da muss ich nochmal konzeptionell ran mit meinen Verzeichnissen...

    Zitat

    Wäre eigentlich denkbar, eine Art Zeilennummerstart für die generierten Zeilen einzusetzen?


    Gibt es schon, den ' Kommentar mit einem #<Start>,<Schrittweite>:

    Code
    '#100,10
    (irgendwelche Codezeilen)
    '#1000,5
    (irgendeine Unterroutine)
    '#2000,5
    (noch eine Unterroutine)

    Das war eine meiner ersten Erweiterungen zum Label -> Line# Umwandeln, weil ich es gerne ordentlich habe :)

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Oh, äh, ja, ich habe natürlich nicht RTFM ;)

    C64Studio: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- C64Studio WIP: Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • Hehe, dazu müsste ich erstmal W(rite)TFM :rolleyes:
    Und meine kleine Webseite zu BasEdit, die noch nie schön war, ist jetzt auch noch völlig überaltert, da stimmt ja kaum noch was, noch so eine Neben-Baustelle...

    Egal, wer braucht schon Doku, wenn man ihn mit unbekannten Features erschlagen kann :)

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Neue Version 1.35 hochgeladen

    Code
    - Der mittige waagerechte Strich wird jetzt korekterweise als CHR(96) und nicht mehr als CHR(192) eingefügt über das F2 Character Fenster
    - Zahlen in wissenschaftlicher Notation werden jetzt erkannt (1E+09)
    - Erweiterungen an der Erkennung von logischen Ausdrücken in Zusammenhang mit Zuweisungen an numerische Variablen

    Damit funktionieren jetzt auch Zuweisungen wie

    Code
    10 A=-(LEFT$(A$,1)="N")

    Vorher wurden nur numerische Vergleiche akzeptiert...

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Neue Version 1.36 hochgeladen:

    Code
    - Pfadbehandlung beim Laden/Speichern überarbeitet

    Die Dateien für Chargen, TokenFile und PetCat aus der BasEdit.Ini werden jetzt immer in fest definierten Unterverzeichnissen zum BasEdit-Verzeichnis (AppDir) gesucht:

    Code
    ' base dir for pathes is application directory!
    ' relativ pathes no longer supported!
    ' 
    ' Character ROM files will be searched in AppDir\Fonts\
    ' Basic Token Files will be searched in AppDir\Basic-Tokens\
    ' ASCII tokenizer files will be searched in AppDir\ASCII-Tokenizer\
    ' BasEdit.Ini will be searched in AppDir\

    Bitte passt Eure BasEdit.Ini's entsprechend an und enfernt aus den Einträgen für Chargen, TokenFile und PetCat alle relativen oder absoluten Pfadangaben. Nur die reinen dateinamen dürfen da noch stehen!

    Für Lade-/Speichervorgänge für PRG/PETSCII/ASCII-Dateien sowie DiskImages und Projekt-Dateien wird ein WorkingDir mitgeführt, das jeweils auf das zuletzt benutzte Verzeichnis verweist und für die Öffnen/Speichern-Dialoge als StartDirectory gilt. Nach Programmstart ist das gleich dem AppDir, es sei denn, man hat per Drag and Drop eine Datei übergeben, dann ist das Verzeichnis dieser Datei das aktuelle WorkingDir.

    Projekte erwarten jetzt immer ihre PRG und TXT-Dateien im gleichen Verzeichnis wie die Projektdatei, außerdem dürfen die Basic-Token- und ASCII-Tokenizer-Dateien nur entweder im Projektverzeichnis oder in ihren jeweiligen Unterverzeichnissen relativ zum AppDir liegen (in dieser Reihenfolge werden sie auch beim Laden gesucht). Damit kann man Projekte schön in Unterverzeichnissen anlegen und ohne Pfadprobleme zwischen verschiedenen Rechnern austauschen.

    Mal schauen, wo's jetzt noch hakt, ich hab bestimmt wieder irgendwas vergessen...

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.

  • Mmh, ich wollte eigentlich mal meinen ersten Post editieren, aber da gibt es keinen Edit-Button!? Genaugenommen finde ich gerade überhaupt keinen Edit-Button, um eine ältere Post von mir zu überarbeiten, komisch. Ich weiß aber, dass ich das schonmal gemacht habe...

    Egal, ich dachte mir, nach so vielen Änderungen an BasEdit könnte ich mal einen aktuellen Screenshot und eine FeatureListe hinterlegen, damit Neuankömmlinge wissen, was sie erwartet :smile:

    Könnte vielleicht ein Admin diese Post nach vorne setzen oder so?

    Bitte melde dich an, um dieses Bild zu sehen.

    Und hier die Features:

    Basic V2 Programme unter Windows editieren: Bitte melde dich an, um diesen Link zu sehen.