@RamsesSie zeigen nur auf wie aktiv das Produkt vom Team unterstützt und unterhalten wird.
was hat "das" Team mit den "Core"-Mitglieder von harbour zu tun
![Question :?:](./images/smilies/question.gif)
ausser den Cl*pper LIBs werden nur Constributionen mitgeliefert für die deren Autoren zuständig sind.
beim zusammenstellen eines Paket aus den Constributionen muss ich mich um die LIB selbst kümmern die auch abhängt vom C-Compiler und der OS Platform ist.
nun erwartest du das es mit FreeBSD funktioniert ... wie viel % arbeiten mit FreeBSD im Gegensatz zu Windows ...
@Hubertsind aber Antworten in Harbour auf Fragen in Xbase++ ... denn die sind sinnlos für den Fragenden
sind die NICHT den die beinhalten Ideen wie es in anderen Dialekten gelöst wurde.
ob "man" die Informationen "versteht" und "umsetzten" kann ist dann noch eine andere Sache
@MarcusIst die Sprache Xbase langsam oder der Datenzugriff via DBF? Ob ein Fenster 1 oder 1,5 sec dauert, >macht doch nicht den Unterschied, länger dauert das nicht, wenn man den Dateizugriff aussen vorlässt
was ich nun im Vergleich sagen kann
Antwort 1 : Speicheranforderung
es ist die GUI, eine Console App ist, für den User schneller.
für die GUI Parts muss jedes mal Speicher angefordert werden und Control welche "Child" haben muss man "einzeln" per ADDITEM() "füttern".
wenn ich ein Array übergeben kann, für das ich den Speicher anfordere, ist das viel schneller
Antwort 2 : alte Controls
der "DbSkipper" ist ein typischen xBase "Relikt" zum navigieren in einer DBF
der direkte Zugriff, insbesondere im Netzwerk, verlangt nach schnellen Zugriffszeiten.
unter Windows wird gewöhnlich ein GRID ( WC_LISTVIEW ) verwendet
"früher" hat man per ADDITEM() das GRID aufgefüllt was maximal 65535 Einträge haben durfte.
dann konnte man mit LVM_SETITEMCOUNT den Speicher für ein Array ganzes anfordern
mit dem LVN_GETDISPINFO Event "sagt" mir dann das GRID "welche" Daten er anzeigen möchte.
solche Controls haben sind für grössere Datenmengen als ein Browse ausgelegt
Antwort 3 : 1 x CPU
kennt Ihr noch alte Drucker die eine DOS App "lahm" gelegt hat wenn die druckte ?
bei nur 1 x CPU wird unter GUI nun ständig "lahm" gelegt und ist inzwischen eher der Flaschenhals als RAM, Netzwerk oder NVM / SSD
so viel ich verstanden habe wurde die harbour VM mächtig aufgebohrt.
durch MT=YES wird der Code nicht "multi-threading-fähig" aber man kann Aufgaben "umleiten" die sich z.b. um die Grafik Ausgabe kümmern.
---
GDI32 ist das was Xbase++ bis v1.9 verwendet hat. GDIPULS wäre der nächste Schritt gewesen.
nun setzt Alaska auf "HTMLayout", was open Source wie PostgreSQL ist, um es native einzubinden.
bei der Chrome Engine weiss ich das die Hardware unterstützt wird aber nicht bei "HTMLayout".
deshalb gibt es mit "Scitar" den Nachfolger von "HTMLayout" was nicht mehr Supported wird.
es ist wiedermal eine alte Technik die eingeführt wurde wo andere aufgehört haben um neue Techniken einzuführen wie damals mit ActiveX.
---
wie kann man eine Xbase++ App schneller machen :
vorweg : erwartet nicht 100 & Steigerung durch die Tips
64 Bit OS statt 32 BIT OS.
im SubSystem hat man meisten "mehr" Speicher als unter 32 Bit OS.
auf Gadget und Tools verzichten die als 32 Bit laufen. umrüsten auf die 64 Bit Version wenn möglich
für Hacker :
alles "abschalten" was man an Diensten & Co nicht ständig benötigt und 32 Bit ist.
GUI Dialog mit Visible := .F. erzeugen und mit Show() anzeigen.
Controls vorher auffüllen
ich liebe SkinFrameWork aber das kostet Zeit wie Ownerdraw oder Customdraw.
muss es ein XbpBrowse() sein oder reicht ein XbpQuickBrowse()
ein "Kleines" Fenster ist schneller aufgebaut als ein grosses.