Beiträge von H.Brill

Aufgrund von notwendige Wartungsarbeiten am Server kann es zu kurzen Downtimes und längere Ladezeiten kommen.

  • Random Access Dateien - Nostalgie läßt grüßen

    Das scheint auch nicht zu funktionieren. Hatte auch schon mit Set("FileMode", N)

    rum gespielt. Früher gab es mal in Turbo Pascal den Befehl TRUNCATE, der eine

    angebene Anzahl Bytes hinten an der Datei abschnitt. Wenn man vorher durch geschicktes

    Umsortieren den zu löschenden Datensatz ans Ende schob, wurde der dann gelöscht.

    Wenn man denn auch ein richtiges FileHandle hätte, könnte man mit der Kernel32.dll

    und der File-Api das End Of File neu setzen. Geht aber wegen des echten fehlenden Handle

    nicht. Es gibt ja nur Kanal-Nummern von 1-99. Auch die Funktion Assign() gibt nur eine

    solche zurück. Und alle Dateioperationen mit API machen, möchte ich auch nun wieder nicht.


    Ich vermute mal, daß RGH einen profaninternen Speicher nicht freigibt, bzw. beim

    wiederholten Schreiben nicht dementsprechend neu dimensioniert. Somit bleiben auch

    Reste, wenn der neu zu schreibende Bereich, den wir dann neu dimensionieren, halt

    kleiner, als der alte profaninterne ist. Ob RGH vergessen hat, dies zu berücksichtigen,

    oder ob es gar nicht vorgesehen war, bleibt halt offen. Wir haben ja mehrer Bereiche,

    wie RegEx, Json, openGL usw., die nur rudimentär implementiert sind.

  • Random Access Dateien - Nostalgie läßt grüßen

    Ich habe das Problem mal nachvollziehbar gemacht.

    Offensichtlich löscht Erase #|datei nicht richtig. Der letzte Eintrag der Datei

    kommt dann immer zweimal. Auch ein Rewrite hilft da nicht.

    Wenn man mit einem Texteditor die Datei anschaut, ist der Datensatz mit "Käse"

    auch zweimal vorhanden, aber wieso ? Der ist doch nur einmal geschrieben worden.

    Auch ein Assign datei, "", das das Dateihandle löscht, brachte nichts.

    Mache ich da jetzt was falsch oder ist meine Vermutung richtig ?

  • Random Access Dateien - Nostalgie läßt grüßen

    Ich habe das Programm noch um eine Löschfunktion erweitert.

    Wenn man im Grid einen Eintrag wählt, soll dieser gelöscht werden.

    Die Datensätze stehen in einem Array mit Structur. Gelöscht wird mit

    ArrDel ..... Die Datei wird Erase #1 gelöscht und dann neu eingelesen.

    Der Eintrag scheint auch im Array gelöscht zu werden, aber beim Neueinlesen

    stimmt was nicht.

    Kann jemand meinen Denkfehler (Knoten) lösen ?

  • Random Access Dateien - Nostalgie läßt grüßen

    Hallo,

    Für die Nostalgiker unter euch, habe ich eine Art Random Access Datei aus Bereichen gemacht.

    Etwa wie früher aus BASIC gewohnt. Statt FIELD .... geht es hier mit STRUCT.

    Probiert mal aus, ob ihr noch einen Fehler findet. Ansonsten ist es mal ein Anfang.

  • Speed-Test

    So, habe jetzt auch mal die MoveListProc einbezogen. Ist ja auch noch eine Möglichkeit.

    Scheint, als wäre die MoveListProc etwas langsamer, als das normale Kopieren.

    Testet mal, was bei euch so rauskommt.

  • Wait

    Naja, ich dachte jetzt, das normale END muß ja auch für was gut sein.

    Habe es ja deshalb immer benutzt, um einen sauberen 'Abgang' des

    Programms zu haben. Und hinter dem End steht ja auch nichts mehr,

    also endet dort der Code auch und es wird auch aufgeräumt (laut deiner Aussage oben).

    Also lasse ich das END einfach weg, da es nichts bringt, außer halt, daß man

    einen Exitcode dranhängen kann.

    Am sichersten scheint da noch die USERMESSAGE $10 zu sein.

    Wie auch immer, ich nutze es wie gehabt, da ich meistens noch ein Button zum

    Beenden (als zweiter Ausgang) anbiete. Wenn ich das auch sauber haben will,

    kann ich ja ein

    SendMessage(%HWnd, $0010, 1, 0)

    dem noch offenen Hauptfenster schicken.

  • Speed-Test

    Habe mal (gerade wegen den Move("...ToList", ...) Funktionen einen Speedtest gemacht.

    Ist ja schon erstaunlich.

  • Wait

    Na, gut zu wissen.

    Und woher weißt du, daß WaitEnd sauber aufräumt, da du selber bis vor 3 Stunden

    den Befehl gar nicht kanntest ?

    Oder hast du heimlichen Kontakt mit RGH ?

    Steht ja auch nirgends im .net Forum.

  • Wait

    Na dann war es ja gut, daß ich das rausgekramt habe.

    Für so kleine Sachen daheim ist es ja gut. Spart dann eine Zeile.

    Ein END nach einem Waitkey/Waitinput macht im Prinzip das gleiche,

    nur daß man noch zusätzlich mit einem Tastendruck beenden kann.

    Mit der Vermutung, daß END auch aufräumt. Ich habe mir sowieso angewöhnt,

    immer ein END zu setzen.

    Ansonsten mache ich ja viel mit GUI, wo ich dann entweder per

    UserMessage $10 nach der Warteschleife brav mein END setze.

    Vielleicht finden wir ja noch ein paar vergessene Goodies.

  • Wait

    Wirklich sehr praktisch.

    Da reagieren WaitInput & WaitKey auch drauf und hören auf zu warten.

    Vielleicht ist ja WaitEnd sauberer und räumt zum Schluß noch auf.

  • "Excel" Control DLL LibXL https://www.libxl.com/ Zugriffsfehler

    Ja, da schreibst du aber in eine Datei, die mit Set("SQLFile", Name)

    festgelegt ist und somit wieder extra Zeit benötigt. Ich meinte statt Modusnummer

    (-1, 0, 1, 2) direkt das Handle des Listview als letzten Parameter. Steht ja auch so in der Hilfe :

    wenn modus > 2 wird das Handle des LV erwartet. Das ergibt einen Schritt weniger, da

    du dann nicht mehr von der Listboxliste in das LV moven mußt.

  • Wait

    Hallo,

    Beim Stöbern in Quellcodes bei xprofan.net und manchmal auch hier,

    bin ich auf

    WaitEnd

    gestoßen. Schlucken tut das der Interpreter/Compiler, wird aber in der Hilfe nicht erwähnt.

    Was macht das genau ? WaitKey, WaitInput usw. warten ja auf eine Taste.

    Schreib jetzt keiner, daß das auf das Ende von Profan wartet. :zorro:

  • Shader in XProfan bzw. Debug von call() von glShaderSource

    Zitat von SvenB

    Es ist wohl unüblich einen Pointer auf einen String direkt zu verwenden... wieder etwas gelernt und mir ist nun auch klar, warum in der Definitionsbeschreibung zwei Sternchen vor dem Parameter waren.

    Das mit den 2 Sternchen ist wohl C/C++ - Manier.

    Weis ich noch von damals, daß das ein Zeiger auf einen Zeiger ist. Ich glaube, PureBasic

    hat auch so was ähnliches : normaler Zeiger = * , Adrresse darauf = @* glaube ich.

    Es ist aber auch üblich, daß die API gerne einen Bereich mit Strings + jeweils Chr$(0)

    zurück gibt. Also wäre die saubere Methode :

    Code
    Dim Bereich, 256
String Bereich, 0 = "#version 330 core", "layout (location = 0) in vec3 aPos;",\
"layout (location = 1) in vec2 aTexCoord;", "out vec2 TexCoords;", "out vec3 FragPos;"\
"void main() {",  "gl_Position = vec4(aPos, 1.0);",  "TexCoords = aTexCoord;", \
"FragPos = aPos;", +"}"
call(glShaderSource&, vertexShader&, 1,Addr(Bereich),0)

    Würde mich interessieren, ob das auch geht.

    Aber da war ich mit der Vermutung mit der Stringvariablen auf dem halben Weg.

    Aber klasse, daß es jetzt funktioniert.

  • Shader in XProfan bzw. Debug von call() von glShaderSource

    Mit CALL ist es beim Absturz immer übel.

    Hast du auch diese Fehlermeldung, wie angehängt bekommen

    oder nur reiner Absturz ?

    Muß man mal weiter probieren. Es hängt ja nur an dem einen CALL hinter Waitkey.

    Hast du auch schon mal

    glCreateShader&, glShaderSource&

    als POINTER übergeben ? Klar, Nummer ist Nummer. Probieren kann man ja mal.

    Ich hatte mal vor Jahren auch so was, wo ich dann einen Pointer übergab.

    Weiß aber jetzt nicht mehr bei welcher API oder wo.

    Oder gibt es Unterschiede zwischen deinem eof$ und "...\n" ? Oder vielleicht nur ein

    Chr$(0) ?

    Bereich statt vertexShaderSource$ hast du auch schon probiert ? Gerade bei der API

    hatte ich schon öfter erlebt, daß ein String ($) nicht ging, aber dafür ein Bereich.

    Hat RGH auch irgendwo in der Hilfe geschrieben, daß bei API Bereiche besser sind.

  • "Excel" Control DLL LibXL https://www.libxl.com/ Zugriffsfehler

    Zitat von A.Berse

    Ich werde einfach mit den Alternativen wie PureBasic etc.... auch nicht warm.

    Da sind du und ich nicht die einzigen. Die Debug-Ausgaben, wenn man was ausprobieren

    möchte, gefallen mir da auch nicht sonderlich. Und dann noch die Klimmzüge für eine

    gewöhnliche Eventschleife.


    Diese unschönen Ladeeffekte wirst du anders auch haben, wenn du die Grids von Hand

    befüllst. Kommt dann auch auf die Menge der Datensätze an. Außerdem wird (X)Profan

    als Interpreter nicht so schnell sein. Aber vielleicht hilft es schon, wenn du beim händischen Befüllen

    die GridBox/Listview vorher ausblendest und danach wieder sichtbar machst. Ist ja auch so eine

    gängige Methode wegen des Neuzeichnens.


    Vielleicht könnte man auch über SQL (oder ODBC-Treiber) noch was erreichen.

    Was ich meine : Bei SQLExec() gibt es ja den Modus > 2, der dann das Handle einer

    List/Gridbox übernimmt bzw. die SELECT - Anweisung die Befüllung des Grid übernimmt.

    Ob das nun ein Handle der Listview.dll oder der XProfaneigenen GridBox ist ist ja egal.

    Könnte man ja beides mal ausprobieren. Man hätte mal auf jeden Fall den Schritt des

    händischen Befüllens gespart. Ob man vlt. auch über Firebird bzw. SQLITE schneller

    ist, weiß ich nicht.

  • "Excel" Control DLL LibXL https://www.libxl.com/ Zugriffsfehler

    Wozu brauchst du sie denn ?

    Um Daten zu generieren, die mit Excel angezigt werden sollen, geht

    ja auch das .csv Format. Vorteilhaft bei Excel ist halt der Diagramm-

    Modus und daß man Formeln für die Spalten hinterlegen kann.

    Für z.b. editierbare Gridboxen usw gibt es ja genug Vorlagen (Codes)

    bei XProfan.net. Ansonsten kann ich dir noch die Listview.dll von

    Frank Abbing empfehlen. Wenn du die nicht hast, die habe ich mal

    vor 2 Jahren hier eingestellt :

    DLLs/Listview - 1 XProfan

    Und wenn du sogen. Mappen brauchst, kannst du sie ja auch gut mit einem

    TabControl nachbilden und dort hinein jeweils ein Listview.