Hello, Guest the thread was viewed608k times and contains 4831 replies

last post from Goodwell at the

C64 Studio - Entwicklungsumgebung

    Quote from frankyman1969

    Hallo @Endurion,


    im aktuellen WIP lassen sich keine D64-Images mehr öffnen. Es erscheint eine Fehlermeldung.

    Ja, stürzt nach dem Öffnen eines D64 bei mir auch so ab. WIP 7.8.61 .NET6

    Hatten wir so einen Bug nicht letztens schon?


    Es funktionierte noch in der WIP Version 7.8.54


    Endurion


    Dies sind die kompletten Details der Fehlermeldung:



    Informationen über das Aufrufen von JIT-Debuggen

    anstelle dieses Dialogfelds finden Sie am Ende dieser Meldung.


    ************** Ausnahmetext **************

    System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

    bei RetroDevStudio.Documents.FileManager..ctor(StudioCore Core, String Filename) in D:\projekte\C64Studio\C64Studio\Documents\FileManager.cs:Zeile 42.

    bei RetroDevStudio.MainForm.OpenFile(String Filename) in D:\projekte\C64Studio\C64Studio\MainForm.cs:Zeile 6222.

    bei RetroDevStudio.MainForm.ApplyFunction(Function Function) in D:\projekte\C64Studio\C64Studio\MainForm.cs:Zeile 4926.

    bei System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)

    bei System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)

    bei System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)

    bei System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)

    bei System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)

    bei System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)

    bei System.Windows.Forms.Control.WndProc(Message& m)

    bei System.Windows.Forms.ToolStrip.WndProc(Message& m)

    bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)



    ************** Geladene Assemblys **************

    mscorlib

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9266.0 built by: NET481REL1LAST_B.

    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll.

    ----------------------------------------

    C64Studio

    Assembly-Version: 7.8.61.0.

    Win32-Version: 7.8.61.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/C64Studio.exe.

    ----------------------------------------

    System.Windows.Forms

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9256.0 built by: NET481REL1LAST_B.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll.

    ----------------------------------------

    System

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9266.0 built by: NET481REL1LAST_B.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll.

    ----------------------------------------

    System.Drawing

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll.

    ----------------------------------------

    WeifenLuo.WinFormsUI.Docking

    Assembly-Version: 1.0.0.0.

    Win32-Version: 3.1.0.0.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/WeifenLuo.WinFormsUI.Docking.DLL.

    ----------------------------------------

    WeifenLuo.WinFormsUI.Docking.ThemeVS2005

    Assembly-Version: 1.0.0.0.

    Win32-Version: 3.1.0.0.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/WeifenLuo.WinFormsUI.Docking.ThemeVS2005.DLL.

    ----------------------------------------

    HexBox

    Assembly-Version: 1.5.0.0.

    Win32-Version: 1.5.0.0.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/HexBox.DLL.

    ----------------------------------------

    FastColoredTextBox

    Assembly-Version: 2.16.11.0.

    Win32-Version: 2.16.11.0.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/FastColoredTextBox.DLL.

    ----------------------------------------

    System.Configuration

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll.

    ----------------------------------------

    System.Core

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9266.0 built by: NET481REL1LAST_B.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll.

    ----------------------------------------

    System.Xml

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll.

    ----------------------------------------

    Accessibility

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll.

    ----------------------------------------

    SourceControl

    Assembly-Version: 0.0.0.0.

    Win32-Version: 0.0.0.0.

    CodeBase: file:///C:/Users/frank/OneDrive/Dokumente/C64Studio/SourceControl.DLL.

    ----------------------------------------

    System.resources

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.resources.dll.

    ----------------------------------------

    mscorlib.resources

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/mscorlib.resources/v4.0_4.0.0.0_de_b77a5c561934e089/mscorlib.resources.dll.

    ----------------------------------------

    System.Windows.Forms.resources

    Assembly-Version: 4.0.0.0.

    Win32-Version: 4.8.9032.0 built by: NET481REL1.

    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms.resources/v4.0_4.0.0.0_de_b77a5c561934e089/System.Windows.Forms.resources.dll.

    ----------------------------------------


    ************** JIT-Debuggen **************

    Um das JIT-Debuggen (Just-In-Time) zu aktivieren, muss in der

    Konfigurationsdatei der Anwendung oder des Computers

    (machine.config) der jitDebugging-Wert im Abschnitt system.windows.forms festgelegt werden.

    Die Anwendung muss mit aktiviertem Debuggen kompiliert werden.


    Zum Beispiel:


    <configuration>

    <system.windows.forms jitDebugging="true" />

    </configuration>


    Wenn das JIT-Debuggen aktiviert ist, werden alle nicht behandelten

    Ausnahmen an den JIT-Debugger gesendet, der auf dem

    Computer registriert ist, und nicht in diesem Dialogfeld behandelt.

    Ich hätte auch noch einen.

    Geht wieder mal um Breakpoints.

    Wenn ich in der Zeile mit dem Breakpoint stehe


    Wenn ich am Anfang der Zeile stehen und Enter drücke rutsch der Breakpoint mit. Das passt.

    Wenn ich ab nach dem ersten Zeichen stehen oder auch am Ende der Zeile und dann Enter drücke, bleibt der Teil vor dem Cursor stehen, ein möglicher Rest der Zeile rutscht in die nächste Zeile und der Breakpoint mit.


    pasted-from-clipboard.png


    Schön wäre es in dem Fall das der Breakpoint nur dann mitgeht wenn man am Anfang der Zeile steht, ansonsten sollte der BP stehen bleiben.

    Das klingt so einfach, hat es aber in sich :)


    Das direkt einzubauen ist simpel, wenn es aber ans Undo geht, wird es knifflig. Beim Source-Editor gibt es Undo nur für die Textbox. Das Verschieben der Breakpoints wird da indirekt über Events gelöst. Da muss ich mich mal reingraben, ob man das anhand eines Undos erkennt, ob ein Breakpoint am oberen Ende nach oben rutschen muss, oder bleiben kann, wo er ist.

    Das glaube ich dir aufs Wort. Mir würde es reichen wenn der Breakpoint beim reinen Tippen sich richtig mit bewegt. :-)

    So, das mit den Breakpoints scheint jetzt so zu klappen. Unterwegs bin ich auf einen dämlichen Bug gestossen, der jeden Breakpoint x-fach eingetragen hat, wobei x die Anzahl der Assembler-Dateien in einem Projekt war (fragt nicht).


    Der Titel im FileManager wird jetzt auch gesetzt.


    Neue WIP-Version!

    Quote from Endurion

    Oh, da habe ich nicht vorgesehen, dass man absolute Pfade angibt. Guck mal in die "Compiler Messages", da steht der vollständige Pfad. Der sieht vermutlich so aus <Dein Pfad zur Datei>\n:\daten\....

    Ich habe das mal eben bei mir getestet. Version 7.8.64.

    Wenn ich einen relativen Pfad angebe der existiert, dann wird dort die Datei gespeichert.

    Existiert der Pfad nicht, dann erscheint die Meldung sowohl im Output als auch in den Compilermessages ohne den Hinweis, dass die Datei nicht geschrieben werden konnte.

    Code
    1. Wrote labels to file 'C:\Projekt\cloud\Projekt\C64\pabasic3\123\pabasic.vars'

    Das Verzeichnis 123 existiert nicht.


    Gebe ich einen absoluten Pfad an dann erhalte ich ebenso die Meldung

    Code
    1. Wrote labels to file 'C:\Projekt\cloud\Projekt\C64\pabasic3\C:\Projekt\cloud\Projekt\C64\pabasic3\pabasic.vars'

    Jedoch wieder kein Hinweis, dass die Datei nicht gespeichert wurde.

    Ah, ja, die Größe ist getrennt vom Modus. Ist ein bisschen eigenwillig. Die 40x25 kommen vom Default-Modus, der ist nun mal C64 40x25.


    Ich ändere die Größe nicht, weil die Bildschirmdaten nicht durchs Ändern des Modus gelöscht werden sollten.


    Es schwebt mir schon länger im Kopf herum, dass man bei einem Projekt evtl. das Zielsystem angibt, und dann fangen die diversen Editoren mit passenden Voreinstellungen an. Dann denke ich immer, was, wenn man da mischen möchte, dann muss man ja .. Eichhörnchen!

    Moin!


    Folgender Anwendungsfall: Ich habe ein prg, welches von $0800 bis $e000 geht. Das kann ich als Standalone zum testen kompilieren und ans U64 schicken oder im VICE starten (RAM injection aktiviert). Kein Problem. Lade ich das gleiche File via WiC64 (weil es eigentlich nachgeladen wird und ich auch das Szenario mal testen will) wird das nix, weil er den Bereich $d000-dfff über das I/O bügelt.


    Was ich mir wünschen würde bzw. benötige, wäre folgende Möglichkeit mit einem Tastendruck:

    1. kompillieren des kompletten Codes ($0800 - $fxxx) nach "Dateiname.prg",cbm

    2. Kompilieren des Bereichs $0800 bis irgendwas unter $d000 nach "Part1",plain

    3. Kompilieren des Bereichs $e000 bis Irgendwas unter $fffe nach "Part2",plain


    Mehrere !to-Anweisungen gehen ja nicht. Gibt es einen gangbaren Weg das zu bewerkstelligen, ohne dass ich jedesmal die komplette Struktur ändern muss?



    EDIT: Ach verdammt, kaum lieg ich im Bett kommt mir die Erkenntnis! Hab die ganze Zeit drüber gegrübelt, wie das im C64-Studio hinzubekommen ist...dabei ist die Lösung wahrscheinlich ganz trivial: Den WiC64-Code so anpassen, dass er ins RAM lädt. *facepalm*

    Nun steh ich aber nicht mehr auf...oder doch...sollte ja schnell gehen...:sleeping:

    Alternativ könntest du auch die Post-Build-Events verwenden. Nachdem das vollständige .prg vorliegt, zerpflückst du das. Das geht mit diversen regulären Tools, aber zur Not auch mit dem $(MediaTool), da kann man auch binär-Dateien bearbeiten.