FAQ · Clipper2Web

Frage: Eine Xbase/Harbour-EXE läuft als App, startet aber als Windows-Dienst auf Windows 11 25H2 nicht (Fehler 1053). Main() scheint nie erreicht zu werden. Was sind die typischen Ursachen und wie behebt man es zuverlässig?

Antwort (Kurzfassung): 1053 signalisiert, dass der Dienst nicht rechtzeitig antwortet. In der Praxis sind es fast immer Arbeitsverzeichnis/DLL-Pfad, gemappte Laufwerke, blockierende INIT/DBESYS/APPSYS oder das 30-Sekunden-Timeout. Behebe das mit festem AppDirectory, UNC-Pfaden, frühem Logging und (falls nötig) höherem ServicesPipeTimeout.

• Arbeitsverzeichnis fixen: Dienste starten aus C:\Windows\System32. Setze per NSSM AppDirectory = C:\webserver oder wechsle im INIT PROCEDURE ins EXE-Verzeichnis.
• Keine gemappten Laufwerke: X:\ existiert im Dienst nicht. Verwende UNC (\\server\share) und hänge ggf. Abhängigkeit LanmanWorkstation ein: sc config MeinDienst depend= Tcpip/LanmanWorkstation.
• Früh-Logging + INIT entkernen: Erste Zeile in INIT/DBESYS/APPSYS → Log schreiben, UI-Aufrufe strikt vermeiden, lange I/O auslagern.
• Timeout erhöhen (falls wirklich nötig): HKLM\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout (DWORD, ms) z. B. 120000, danach Neustart.
• Fehler schnell sichtbar machen: Mit ProcMon auf NAME NOT FOUND / ACCESS DENIED filtern; häufig fehlende DLL oder falscher Pfad.
• ServiceFailureActions: automatische Neustarts konfigurieren, um transienten Startproblemen zu begegnen.
• Bitness & Runtimes: 32-Bit-EXE → 32-Bit-DLLs; Redistributables bereitstellen oder statisch linken.
• Defender/AV-Ausnahmen: App-Ordner kurzzeitig ausschließen, um On-Access-Blockaden auszuschließen.

Minimal-Snippet (Harbour) für dienstsicheren Start:

INIT PROCEDURE EarlyInit()
       LOCAL cExe := hb_FNameDir( hb_argv(0) )
       IF !Empty(cExe)
          FChDir(cExe)
          hb_cwdSet(cExe)
       ENDIF
       hb_MemoWrit("C:\webserver\service.log", Time()+" init ok"+hb_eol(), .T.)
    RETURN

Best-Practice Setup (NSSM):

nssm install MeinDienst "C:\webserver\meinservice.exe"
    nssm set MeinDienst AppDirectory "C:\webserver"
    nssm set MeinDienst AppStdout   "C:\webserver\out.log"
    nssm set MeinDienst AppStderr   "C:\webserver\err.log"
    sc config  MeinDienst start= delayed-auto
    sc config  MeinDienst depend= Tcpip/LanmanWorkstation

Wann ist es sicher gefixt? Wenn das Log aus INIT erscheint, Main() schreibt „enter“, und der Dienst binnen 30 s den „running“-Status erreicht – ohne UI-Aufrufe, ohne gemappte Laufwerke, mit eindeutigen Pfaden.

Frage: Ich möchte ein Delphi-Programm schreiben, das über das Internet auf ein DataDictionary zugreift (MySQL/MariaDB oder ADS). Brauche ich dafür einen Virtual Server, und gibt es eine schnelle, sichere Lösung für einen Testbetrieb bis Ende Januar?

Antwort (Kurzfassung): Es gibt zwei bewährte Wege. Klassisch geht es mit einem VPS und hart abgesichertem DB-Port. Moderner und für Tests oft schneller ist ein Cloudflare Tunnel mit Zero-Trust und MFA, bei dem kein Port öffentlich ist.

• Variante A – VPS (klassisch): Virtuellen Server mieten (z. B. df.eu/AWS), MySQL/MariaDB oder ADS installieren, Firewall strikt, TLS aktivieren, nur nötige DB-User. Zugriff über Host/IP und Port (MySQL 3306, ADS 6262); Portweiterleitung nur mit strengen Regeln.
• Variante B – Cloudflare Tunnel (empfohlen): Domain bei Cloudflare, Zero-Trust aktivieren, auf Server/PC cloudflared installieren, TCP-Tunnel auf lokalen DB-Port legen, in Cloudflare Access MFA erzwingen. Client verbindet sich via cloudflared access tcp lokal auf 127.0.0.1:PORT.

Welche Option wählen? Für schnellen, sicheren Testbetrieb Variante B (Tunnel + MFA). Wenn ohne Zusatztool gearbeitet werden soll, Variante A – aber nur mit konsequenter Härtung (TLS, Firewall, Least-Privilege).

Hinweise: Bei ADS zusätzlich Internet-Rechte im DD und Benutzerkonten freischalten. Exponierte DB-Ports vermeiden; Audit-Logs prüfen; Sessions kurz halten.

Frage: Beim Parsen einer XML-Datei mit Chilkat.Xml werden Umlaute zerstört (z. B. „Beh lter“/„Beh?lter“ in :Content). Wie erhalte ich korrekte Sonderzeichen?

Antwort (Kurzfassung): In der ActiveX-Variante liefert Chilkat ohne Einstellung ANSI-Strings zurück. Setze loXml:Utf8 := 1 vor dem Laden und sorge für einen korrekten encoding-Header oder lade mit der passenden Quell-Kodierung. Danach optional in die Ziel-Codepage wandeln.

* Minimalfix
    loXml := CreateObject('Chilkat.Xml')
    loXml:Utf8 := 1                     // vor dem Load!
    IF ! loXml:LoadXmlFile(::cXmlDateiName)
       // Fehlerbehandlung ...
    ENDIF
    cUtf8 := loXml:Content              // korrekt mit Umlauten
    cAnsi := cUTF8ToAnsi(cUtf8)         // nur falls nötig
    

• Header prüfen: <?xml version="1.0" encoding="utf-8"?> (oder korrekte tatsächliche Kodierung).
• Nicht-UTF-8 Quelle: loXml:Utf8 := 1 + LoadXmlFile2(::cXmlDateiName, "windows-1252") bzw. "iso-8859-1".
• Ohne Header: Datei mit Chilkat.StringBuilder:LoadFile(path, "windows-1252") laden und loXml:LoadSb().
• Entities: ä etc. werden mit obigen Einstellungen automatisch korrekt decodiert.

Status: 2025-10-21 gelöst. Ursache: fehlendes/ignoriertes UTF-8-Flag und/oder falscher XML-Header. Fix: Utf8=1 + korrekter Header bzw. LoadXmlFile2 mit passender Quell-Kodierung.

Hinweis: Immer zuerst interne Repräsentation auf UTF-8 bringen, erst am Randsystem in ANSI/OEM konvertieren.

Kurzfassung

• Was bedeutet 7022? Der B-Baum des Index ist zu tief/unbalanciert (zu viele Levels), meist wegen sehr langer Keys, vieler Inserts/Updates oder korruptem Index.
• Was hilft sofort? Reindex – am besten online (ADS baut im Hintergrund neu, hängt nach und tauscht am Ende um).
• Was verhindert das Wiederkehren? Kompaktere Keys (Padding reduzieren), ggf. größere Index Page Size, regelmäßiges Reindex bei hoher Änderungsrate.

Warum passiert das?

Pro Indexseite passen nur begrenzt viele Einträge (Fan-out ≈ Seitengröße ÷ Schlüsselbreite). Breite Keys wie PADR(UPPER(FIRMA),80) verringern den Fan-out ⇒ mehr Ebenen. Viele Inserts in derselben Sortierregion verursachen zusätzliche Splits; irgendwann erreicht ADS das Level-Limit → 7022.

Online-Reindex (ohne alle Benutzer abzumelden)

-- Verfügbare System-Prozeduren anzeigen
    SELECT * FROM system.systemprocedures;
    
    -- Klassisches Reindex (DD-Tabelle)
    EXECUTE PROCEDURE sp_Reindex('MeineTabelle');
    
    -- Falls vorhanden in deiner Version: Online-Reindex
    EXECUTE PROCEDURE sp_ReindexOnline('MeineTabelle');  -- Signatur in system.systemprocedures prüfen
    

Hinweis: Online-Reindex legt eine neue Indexdatei an, pflegt Änderungen nach und tauscht am Ende atomar aus.

Offline-Reindex (Wartungsfenster)

1. Alle Benutzer raus, Backup der DBF/CDX.
2. ARC: Table Maintenance → Reindex oder sp_Reindex('...').
3. Kommt 7022 wieder: Reindex mit größerer Page Size (siehe ADS-Doku zu Index Page Size / AdsIndexPageSize).

Key-Ausdrücke optimieren (Beispiele)

* Schlecht (breit, viel Padding)
    INDEX ON PADR(UPPER(FIRMA),80) + DTOS(DATUM) + STR(NR,10) TAG BIG
    
    * Besser (kompakter, gleiche Sortierlogik)
    INDEX ON LEFT(RTRIM(UPPER(FIRMA)),30) + DTOS(DATUM) + STR(NR,8) TAG N_FIRMA_DAT_NR
    

• Datum immer DTOS() (8 Zeichen).
• Zahlen mit STR(n, festeBreite) möglichst klein halten.
• Lange Kombi-Keys in mehrere kurze Tags aufteilen.

Checkliste „7022 beheben“

1. Backup erstellen.
2. SELECT * FROM system.systemprocedures WHERE name LIKE 'sp_Reindex%'; – Signatur prüfen.
3. Online-Reindex ausführen (oder Offline im Fenster).
4. Falls nötig: Page Size erhöhen und/oder Keys kürzen.
5. Optional: regelmäßiges Reindex einplanen (z. B. monatlich bei hoher Änderungslast).

Feinheiten

• ADS trimmt Keys nicht automatisch: PADR(...,80) bleibt 80 B lang.
• Einzelne Keys werden nie „gesplittet“; gesplittet werden Seiten. Leaf-Seiten sind doppelt verkettet (Range-Scans sind schnell).

Frage: Ein XbpBrowse wird wie ein AChoice genutzt. Nach dem Öffnen dauert die Positionierung; der User tippt bereits und drückt Return. Wegen asynchroner Pfeile via PostAppEvent(xbeP_Keyboard,…) landet der falsche Datensatz. Wie verhindert man das – und wie beschleunigt man das Browse bei großen Fonts/vielen Spalten?

Antwort (Kurzfassung)

• Nie Pfeile posten. PostAppEvent() konkurriert mit User-Events. Synchron navigieren: DB bewegen, Browse refreshen, dann :down()/:applyKey() ohne Queue.
• „Stable-Gate“ setzen. Während der Navigation Eingaben blocken, Event-Queue leeren, erst danach Return zulassen.
• Weniger zeichnen + kleiner Font. Sichtbare Spalten begrenzen, teure Zellen vermeiden, eigenen (kleineren) Font nur im Browse setzen.

Synchron positionieren (robust)

STATIC lNavigating := .F.
    
    PROCEDURE BrowseGotoStable( oBrw, nTargetRec )
       LOCAL nE, u1, u2, o
       lNavigating := .T.
       oBrw:disableUpdate()
    
       IF nTargetRec > 0
          dbGoto( nTargetRec )       // oder: ordSeek( cKey )
       ENDIF
       oBrw:refreshCurrent()         // bei großen Sprüngen: :refreshAll()
    
       oBrw:enableUpdate()
       SysRefresh()
    
       // Alte gepostete Events verwerfen (keine "Return"-Altlasten)
       DO WHILE AppEvent( @nE, @u1, @u2, @o, 0 ) != 0
       ENDDO
       lNavigating := .F.
    RETURN
    
    FUNCTION OnKey( oBrw, nKey )
       IF lNavigating
          RETURN 0                    // Eingaben ignorieren, bis stabil
       ENDIF
       IF nKey == xbeK_RETURN
          RETURN DoAcceptIfStable( oBrw )
       ENDIF
    RETURN oBrw:applyKey( nKey )      // synchron, kein PostAppEvent()
    

„Mitte treffen“ ohne Queue-Rennen

/* oBrw = XbpBrowse, nRec = Ziel-RECNO(), nVis = sichtbare Zeilen */
    PROCEDURE CenterOn( oBrw, nRec, nVis )
       LOCAL nTopRec := Max( 1, nRec - Int( Max(nVis,10) / 2 ) )
       LOCAL nDown   := nRec - nTopRec
       LOCAL nE, u1, u2, o
    
       lNavigating := .T.
       oBrw:disableUpdate()
    
       dbGoto( nTopRec )
       oBrw:refreshAll()
       IF nDown > 0
          oBrw:down( nDown )          // synchron bewegen
       ENDIF
    
       oBrw:enableUpdate()
       SysRefresh()
    
       DO WHILE AppEvent( @nE, @u1, @u2, @o, 0 ) != 0
       ENDDO
       lNavigating := .F.
    RETURN
    

Performance-Killer & sichere Fixes

• Weniger zeichnen: Nur benötigte Spalten anlegen/anzeigen; breite Texte kürzen; OwnerDraw/Bitmaps sparsam.
• Atomic Paint: :disableUpdate() → bewegen → :refreshCurrent()/:refreshAll() → :enableUpdate() → SysRefresh().
• Fonts/DPI: Systemfont nicht ändern. Stattdessen:

  LOCAL oF := XbpFont():new():create( "Arial", 0, -9 )  // ~9pt
      oBrw:setFont( oF )           // kleiner, schneller
      

  Optional monospace (Fixed-Pitch) für messfreie Breiten, falls Layout passt.
• Große Sprünge vs. kleine Moves: Große Sprünge mit :refreshAll(), danach fein mit :down(n). Keine Pfeil-Events posten.
• Event-Queue unter Kontrolle: Während Navigation Return/Keys ignorieren und nach dem Refresh gepufferte Alt-Events verwerfen.

Quick-Win-Messung

LOCAL t := Seconds()
    oBrw:refreshAll()
    ? "Refresh:", Seconds() - t
    

Praxis-Checkliste

1. Spalten straffen und teure Zellen reduzieren.
2. Kleinen eigenen Font via setFont() nur im Browse setzen.
3. Navigation kapseln mit :disableUpdate() … :enableUpdate().
4. Synchron positionieren (dbGoto/ordSeek → :refresh… → :down()).
5. „Stable-Gate“ (Flag + Queue leeren) vor Akzeptieren von Return.
6. Messen (vorher/nachher) und nur wirksame Maßnahmen behalten.

Thread-Update (2025-10-20):

• (Nachtrag #1): Eingaben werden bereits verworfen; Hauptproblem bleibt die Performance bei großen Fonts und langen/breiten Listen.
• Konsequenz: Obige „Weniger zeichnen + kleiner Font + synchrone Navigation“-Kombi priorisieren; PostAppEvent() vermeiden.

Hinweis: API-Namen wie :down(), :applyKey(), :refreshCurrent()/:refreshAll(), :disableUpdate()/:enableUpdate() sind stabil. Bibliotheks-spezifische „Cache/Autosize/Virtual“-Extras bitte einzeln testen und nur bei messbarem Gewinn übernehmen.

Frage: Kann man aus Xbase++ die Bildschirmauflösung temporär reduzieren (z. B. von 1920×1080), damit die App nicht abgeschnitten wird, und später wieder zurückstellen? Der Kunde möchte die Systemauflösung für andere Programme nicht ändern.

Antwort (Kurzfassung): Nicht die Auflösung ist das Problem, sondern die Windows-DPI-Skalierung (125 %/150 %). „Auflösung pro App ändern“ ist nicht sinnvoll. Es gibt zwei praktikable Wege:

• Sofort & ohne Code: Eigenschaften → Kompatibilität → Hohe DPI-Einstellungen ändern und „Hohe DPI-Skalierung überschreiben“ aktivieren, Skalierung durch: „System (Erweitert)“. Verhindert Abschneiden, ggf. leicht unscharf.
• Sauber & zukunftssicher: App als Per-Monitor-DPI-aware deklarieren und Größen/Fonts am DPI-Faktor ausrichten:
  • Manifest: <dpiAware>true</dpiAware> + <dpiAwareness>PerMonitorV2</dpiAwareness>.
  • DPI ermitteln (z. B. GetDpiForWindow()), scale = dpi / 96.0, alle Koordinaten/Schriftgrößen durch scale teilen.
  • Bei Monitorwechsel neu skalieren (Per-Monitor-V2).

Hinweise: Framework-Scaling (z. B. eXpress++) kann das bereits kapseln. PDF/Rendering-Unschärfen treten nur bei der „System (Erweitert)“-Variante auf, nicht bei echter DPI-Awareness.

Status: Stand 2025-10-08. Empfehlung: Kurzfristig Kompatibilitäts-Scaling, mittelfristig Manifest PerMonitorV2 + konsequente DPI-Skalierung in der App.

Optional: Beispiel-Manifest und eine kleine Xbase++/WinAPI-Hilfsroutine zum DPI-Faktor können bei Bedarf ergänzt werden.

Frage: Wie setze ich einen multipart/form-data-Upload wie im cURL-Beispiel um (-F apiKey, -F title, -F description, -F [email protected])? Reicht HttpClient:setAcceptType("multipart/form-data")?

Antwort (Kurzfassung): Nein. Accept betrifft nur die erwartete Antwort. Für den Upload müssen die Formfelder als Body gesetzt und die Datei als eigener Multipart-Part übertragen werden. In Xbase++ erledigst du das mit httpRequest:setParameter() für Textfelder und httpRequest:setFileParameter() (oder äquivalent) für die Datei; der Client erzeugt dann den korrekten multipart/form-data-Body inkl. Boundary automatisch.

• Klarstellung: -F in cURL = Form-Parts (Body), nicht Header. Also setParameter()/AddParameter() statt SetHeader() für apiKey etc.
• Datei-Part: Eine dedizierte Datei-API (setFileParameter("file","hamburg.txt")) ist robuster als Kurzformen; sie setzt Boundary, filename und Content-Type.
• Method/URL: setMethod("POST") und Ziel-URL in :new(...) oder via Request-Objekt setzen.

LOCAL oHC := HttpClient():new("https://url.net/database/saveWithApiKey")
    oHC:setMethod("POST")
    
    oHC:httpRequest:setParameter( "apiKey"     , "APIKEY" )
    oHC:httpRequest:setParameter( "title"      , "Hamburg" )
    oHC:httpRequest:setParameter( "description", "Meine Komplette Liste" )
    
    // Datei-Part → erzeugt automatisch multipart/form-data inkl. Boundary
    oHC:httpRequest:setFileParameter( "file", "hamburg.txt" )
    
    LOCAL cBody := oHC:send()
    ? oHC:getStatusCode(), oHC:httpResponse:statusText
    // ? cBody  // optional anzeigen

oHC  := HttpClient():new("https://url.net/database/saveWithApiKey")
    oHC:httpRequest:setMethod("POST")
    oHC:httpRequest:setContentType("multipart/form-data")  // Boundary wird von der Lib ergänzt
    oHC:httpRequest:AddParameter("apiKey", "APIKEY")
    oHC:httpRequest:AddParameter("file", "@hamburg.txt")   // Datei-Part per @-Kurzschreibweise
    oHC:httpRequest:AddParameter("title", "Hamburg")
    oHC:httpRequest:AddParameter("description", "Meine Komplette Liste")
    cResult := oHC:send()
    nStatus := oHC:getStatusCode()

--BOUNDARY\r
    Content-Disposition: form-data; name="apiKey"\r
    \r
    APIKEY\r
    --BOUNDARY\r
    Content-Disposition: form-data; name="title"\r
    \r
    Hamburg\r
    --BOUNDARY\r
    Content-Disposition: form-data; name="description"\r
    \r
    Meine Komplette Liste\r
    --BOUNDARY\r
    Content-Disposition: form-data; name="file"; filename="hamburg.txt"\r
    Content-Type: text/plain\r
    \r
    <Datei-Binärdaten>\r
    --BOUNDARY--\r

oHC  := HttpClient():new("https://url.net/database/saveWithApiKey")
          oHC:httpRequest:setMethod("POST")
          oHC:httpRequest:setContentType("multipart/form-data")  // Boundary wird von der Lib ergänzt
          oHC:httpRequest:AddParameter("apiKey", "APIKEY")
          oHC:httpRequest:AddParameter("file", "@" + FExpand("hamburg.txt"))   // Datei-Part per @
          oHC:httpRequest:AddParameter("title", "Hamburg")
          oHC:httpRequest:AddParameter("description", "Meine Komplette Liste")
          cResult := oHC:send()
          nStatus := oHC:getStatusCode()   // z.B. 200

<?php
          header('Content-Type: application/json; charset=utf-8');
          echo json_encode([
            'fields' => $_POST,
            'file'   => isset($_FILES['file']) ? [
                'name'   => $_FILES['file']['name'],
                'type'   => $_FILES['file']['type'],
                'size'   => $_FILES['file']['size'],
                'sha256' => hash_file('sha256', $_FILES['file']['tmp_name']),
            ] : null,
          ], JSON_PRETTY_PRINT);

{
            "success": true,
            "id": "f_8a3d",
            "fileName": "hamburg.txt",
            "size": 12345,
            "mime": "text/plain",
            "sha256": "ab12...fe90",
            "message": "Upload gespeichert"
          }

// Erwartetes Format deklarieren (falls JSON):
          oHC:httpRequest:setAcceptType("application/json")
          
          cBody   := oHC:send()
          nStatus := oHC:getStatusCode()
          
          IF nStatus >= 200 .AND. nStatus < 300
             // JSON parsen und auf success/id/checksum prüfen (API-spezifisch)
             // Zusätzlich: Größe/Hash mit lokaler Datei vergleichen, falls geliefert
          ELSE
             // Fehlerpfad: nStatus, evtl. Fehlermeldung aus Body/Headers loggen
          ENDIF

Status: Ergänzt am 2025-10-07 mit „Praxis-Update“ nach erfolgreichem Test der @-Kurzvariante. Empfehlung bleibt: bei Gelegenheit auf Datei-API (setFileParameter) umstellen.

Hinweis: Nur wenn die Library keinen Datei-Part kennt, muss der Multipart-Body samt Boundary manuell gebaut werden.

Frage:
Kann man es so einstellen, dass man mit ENTER nicht nur durch alle Eingabefelder läuft, sondern nach dem letzten Feld automatisch zu den Buttons springt und danach wieder vorne beim ersten Feld anfängt – also ein kompletter Fokus-Ring mit ENTER?

Antwort:
Ja, mit DCGETOPTIONS ENTERMOVE wird ENTER wie TAB behandelt. Damit läuft der Fokus durch alle GETs und Buttons im Tab-Ring und springt am Ende wieder zurück an den Anfang. Alternativ kann man am letzten GET mit bKeyDown oder bPostValid den Fokus explizit auf einen Button setzen. Ein minimales Beispiel:

    FUNCTION Demo()
       LOCAL cName := "", cPhone := ""
       LOCAL oDlg, oBtnOk, oBtnCancel, oLast
    
       DEFINE DIALOG oDlg TITLE "Demo"
    
       @ 1, 2 SAY "Name"    GET cName
       @ 2, 2 SAY "Telefon" GET cPhone OBJECT oLast
    
       @ 4, 2  BUTTON "&OK"      OF oDlg ACTION oDlg:End( IDOK )     OBJECT oBtnOk DEFAULT
       @ 4,12  BUTTON "&Abbruch" OF oDlg ACTION oDlg:End( IDCANCEL ) OBJECT oBtnCancel
    
       // ENTER wie TAB, Fokus läuft im Ring
       DCGETOPTIONS ENTERMOVE
    
       // Letztes GET: ENTER abfangen → Fokus auf OK-Button
       oLast:bKeyDown := {|o,n| If( n==VK_RETURN, ( oBtnOk:SetFocus(), 0 ), NIL )}
    
       DCREAD GUI OF oDlg BUTTONS oBtnOk, oBtnCancel
    RETURN NIL
    

Hinweis:
Das Verhalten hängt von den Optionen ab:

• ENTEREXIT beendet die Maske nach dem letzten GET.
• DEFAULT-Buttons fangen ENTER oft sofort ab.
• ENTERMOVE erzeugt den Fokus-Ring, kann aber je nach TabOrder variieren.

Frage: Bei einem Kunden mit ESET treten beim Einsatz von LoadFromUrl() (Phil) Fehler auf, stets bei dllExecuteCall. Callstack zeigt PCRE_BASE:PCRE_FULLINFO → RegExp():Exec() → ChopUrlIntoLittleBits(). Welche ESET-Einstellung ist zu prüfen?

Antwort (Kurzfassung): Sehr wahrscheinlich kein direkter ESET-Bug, sondern ein Stabilitäts-/Ressourcenproblem im PCRE/RegExp-Pfad (insbesondere, wenn Regex instanz-/threadübergreifend genutzt wird oder der Input Binär-/Sonderzeichen enthält). Workarounds/Optionen:

• Regex vermeiden: URL ohne PCRE parsen (z. B. eigener Parser statt ChopUrlIntoLittleBits() mit RegExp).
• Alternativen nutzen: In Xbase++ 1.90 ASINET-Variante von LoadFromUrl() (andere Syntax) oder in neueren Versionen HttpClient.
• RegExp sicher machen: Keine geteilten RegExp()-Instanzen zwischen Threads; Eingaben begrenzen/validieren; Fehler mit BEGIN SEQUENCE … RECOVER abfangen.
• ESET nur testweise/gezielt: Falls nötig, Prozess/URL in ESET vom HTTPS-/Protokoll-Scan ausnehmen; aber primär Ursache im Code suchen.

Status: Der Thread wurde am 2025-09-30 als erledigt markiert; das Problem trat „ohne nachvollziehbaren Grund“ nicht mehr auf. Es gab parallel auch PDF-Erstellungsprobleme. Vermutung: Ressourcen-/Speicherproblem.

Hinweis: Ein drop-in, regexfreier URL-Parser steht bereit und eliminiert die PCRE-Stelle vollständig.

Frage:
Mir wird angezeigt, dass die Variable GETLIST public sein soll, obwohl ich sie nur als LOCAL deklariert habe. Muss das so oder kann das weg?

Antwort:
GETLIST ist historisch eine PUBLIC-Variable, die von Clipper/FiveWin für die klassische READ-Logik genutzt wird. Viele Bibliotheken initialisieren sie mit PUBLIC GetList := {}. Wenn du in einer Funktion ein LOCAL GetList definierst, überschreibt diese lokale Definition die globale. Der Hinweis erscheint, weil die globale Variante trotzdem existiert.

Praktisch gilt: Entfernen solltest du die PUBLIC GetList nicht, weil Framework-Funktionen sie erwarten. Verwende in deinem Code entweder einen anderen Variablennamen oder belasse es bei LOCAL GetList – das ist innerhalb der Funktion sicher. Eine PUBLIC GetList selbst anzulegen ist nicht empfehlenswert.

Weitere von Alaska automatisch angelegte PUBLIC-Variablen:

• GetList – Array für aktive GET-Objekte (klassische Eingabelogik).
• PromptList – Array für PROMPT/CHOICE-Menüs (Menüsteuerung).
• AppObject – globales Application-Objekt der Runtime.
• oDesktop – Referenz auf den Desktop (Fenster-Umgebung für GUI-Controls).

Hinweis: Diese Variablen sind immer vorhanden, auch wenn du sie nicht selbst deklarierst. Für sauberen Code empfiehlt es sich, eigene Variablen nicht gleich zu benennen, um Überschneidungen zu vermeiden.

Frage:
Wie wird in Fortras der Empfänger bzw. Entladeort angegeben?

Antwort:
Der Empfänger wird mit dem Block CNE (Consignee) beschrieben. Darin stehen Name, Straße, PLZ, Ort und Land der Entladestelle. Falls der tatsächliche Entladeplatz vom Empfänger abweicht, kann zusätzlich ein ADR-Block mit TYP=ULP (Unload Place) oder ein LOC-Segment genutzt werden. Damit bleibt klar: CNE = Auftragsempfänger, ULP/LOC = konkrete Abladestelle.

→ Ausführliche Anleitung und Beispielcode (PDF)

Frage:
Beim Start erscheint die Meldung Fatal RTL installation error – unknown linking mode. Die EXE wurde lokal erstellt, dennoch bricht sie beim Start mit diesem Fehler ab. Was bedeutet die Meldung und wie kann man das Problem beheben?

Antwort:
Die Fehlermeldung weist auf ein Versions- oder Modus-Mismatch zwischen der EXE und den Runtime-DLLs hin. Typische Ursachen sind:

• Falsche DLL im Suchpfad: Eine ältere oder inkompatible RTL-DLL (z. B. XPPRT1.DLL) wird zuerst gefunden.
• Bitness-Mismatch: 32-Bit-EXE trifft auf 64-Bit-DLL oder umgekehrt.
• Gemischte Build-Stände: EXE wurde mit neuerem Service Pack erzeugt, DLLs stammen noch aus einer älteren Version.
• Cache-/Projektreste: Alte OBJ/LIB-Dateien im Projektordner können falsche Link-Informationen hinterlassen.
• Fehlende Rechte: In seltenen Fällen verhindert ein Start ohne Administratorrechte, dass die Runtime korrekt initialisiert werden kann.

Schnelle Tipps

1. Alle alten OBJ/LIB-Dateien löschen und das Projekt komplett neu bauen.
2. Die passenden RTL-DLLs side-by-side zur EXE legen, nichts in System32 oder SysWOW64.
3. Mit Tools wie „Dependency Walker“ prüfen, welche DLL tatsächlich geladen wird.
4. Sicherstellen, dass EXE und RTL-DLL denselben Build-Stand und dieselbe Bitness haben.
5. Auf einer sauberen Test-VM nur EXE + passende RTL starten, um Pfadkonflikte auszuschließen.
6. Falls weiterhin Fehler auftreten: Programm testweise mit Admin-Rechten starten.

Beispiel: Eine EXE wurde mit aktuellem Service Pack erstellt, findet aber beim Start noch eine ältere RTL-DLL im PATH. Ergebnis: unknown linking mode. Lösung: DLLs im Programmordner aktualisieren und Projekt neu bauen. Sollte das Problem bestehen bleiben, hilft oft ein Start mit Admin-Rechten, um Zugriffsprobleme auszuschließen.

Frage:
Eine App läuft einmal mit dpiAwareness im Manifest, einmal ohne – gleicher Code, gleicher Monitor (1920×1080). Ohne dpiAware passt die App exakt, mit dpiAware bleibt ein Rand. Im Debugger werden andere Größen gemeldet (z. B. 1920×1032 vs. 1900×1024 gemessen) und bei maximized entstehen sogar Werte größer als der Bildschirm. Warum stimmt die Größe nicht mehr und wieso zeigt maximized() unterschiedliche Resultate?

Antwort:
Das Verhalten ist normal und hängt mit DPI-Awareness, Fensterrahmen und der Windows-Workarea zusammen:

• DPI-Virtualisierung (ohne dpiAware): Koordinaten werden in 96-DPI-Logik virtualisiert → scheinbar passend, aber nicht echte Pixel.
• Echte Pixel (mit dpiAware): Rahmen, Titelzeile und unsichtbare Resize-Border (~7–8 px) kommen hinzu → sichtbarer Rand.
• Work-Area vs. Monitor-Area: 1920×1080 ist die Gesamtfläche; die Work-Area ist kleiner (Taskleiste abgezogen). Maximized berechnet daraus inkl. Rahmen → WindowRect kann größer als der Bildschirm wirken.
• Messmethoden: GetWindowRect ≠ GetClientRect; DwmGetWindowAttribute liefert oft andere Bounds als Screenshots.

Schnelle Tipps

1. Manifest auf PerMonitorV2 setzen (<dpiAwareness>PerMonitorV2</dpiAwareness>).
2. Immer die Monitor-Workarea verwenden (GetMonitorInfo → rcWork).
3. Fenstergröße mit AdjustWindowRectExForDpi anpassen, damit der Client exakt die Work-Area füllt.
4. Kompatibilitäts-Overrides prüfen/löschen (Registry/EXE-Eigenschaften), da Windows den dpiAware-Status pro EXE cachen kann.

Beispiel: 1920×1032 (Client ohne Taskleiste), 1900×1024 (sichtbar ohne unsichtbare Border) sowie 1936×1048/1926×1038 (maximized inkl. Rahmen/DWM-Outsets) sind konsistent und erklärbar.

Kurzfassung: Ein Nutzer berichtet, dass der Login auf einen FTPS-Server klappt, aber Directory leer bleibt. Ursache ist fast immer die Firewall: FTP/FTPS nutzt neben Port 21 (Kontrollkanal) zusätzliche Datenports für Listings/Transfers.

Hintergrund

• Active Mode: Server sendet Daten von Port 20 → oft von Firewalls/NAT geblockt.
• Passive Mode: Server öffnet zufällige hohe Ports (Passiv-Range). Diese Range muss am Server fest definiert und in der Firewall eingehend erlaubt werden.
• Explizites FTPS (AUTH TLS): gleicher Mechanismus, aber TLS verschlüsselt die Steuerbefehle → klassische FTP-ALGs können nicht „mitlesen“. Daher ist eine sauber konfigurierte Passive-Port-Range Pflicht.

Schnelle Lösungen

1. Wenn FTP/FTPS bleiben muss:
   • Am Server eine feste Passive-Range setzen (z. B. 50000-51000) und diese in der Server-Firewall freigeben.
   • Client auf Passive Mode stellen.
   • Falls vorhanden: FTPS explicit (Port 21) nutzen, nicht „implicit“ (Port 990), und die gleiche Passive-Range öffnen.
2. Empfohlen für Updates/Downloads: auf HTTPS (Port 443) umstellen. Ein Port, überall offen, einfacher Betrieb, moderne TLS-Stacks.

// manifest.json (Server)
{
  "version": "1.2.3",
  "file": "app-1.2.3.zip",
  "sha256": "64-hex-digits-hier"
}