PureBoard

Hallo zusammen,

ich bin vor ein paar Tagen auf PureBasic gestossen und bin gerade dabei, mit der Demoversion zu experimentieren. Ziemlich beeindruckend, aber irgendwie hänge ich in Bezug auf meine Projekte doch noch etwas im Unklaren.

Also: Ich hab's mit Textverarbeitungen. Ich bin mit denen, die es gibt, nicht zufrieden, möchte meine eigene basteln. Ich habe da ein paar schräge Ideen, wie sowas aussehen sollte - will nicht weiter darauf eingehen, nur soweit: sie sind so schräg, daß sich eine Software, die sie verwirklichen würde, wahrscheinlich nur genau 1 Käufer fände: Mich. Also bleibt nur, selber machen.

Unter Windoof sollte schon sein. Aber seit ich um dieses Projekt herumschleiche, suche ich nach Wegen, es nicht in C angehen zu müssen. Ich kann ein bißchen C - gerade gut genug, um zu merken, daß das nichts für mich ist. Zu maschinennah, und allein die Stringverarbeitung unter C ist eine Strafe für Leute, die im letzten Leben was ganz Schlimmes getan haben...

Und nun stoße ich auf PureBasic, das wirklich gut aussieht, und lese in der FAQ sowas wie:
Frage: Was kann man damit machen?
Antwort: Nun - alles.

Wow. Aber... irgendwie habe ich den Eindruck, daß das ein wenig übertrieben ist. Wofür ich keine Funktionen finde, ist schon mal das Elementarste: Auf ein Fenster Text ausgeben, und abfragen, was das Keyboard macht. Ans Keyboard kommt man überhaupt nur heran, wenn man ein Spiel programmiert und den Windows-Schirm wegschaltet - das will ich nicht. Es soll schon ein stinknormales Windoofprog werden; WORD für Wahnsinnige, sozusagen. Aber alle Beispiele füpr textverarbeitende Programme, die ich gefunden habe - sowohl im Web als auch hier im Forum - beruhen letztendlich wieder auf einem Control (bzw. Gadget), das die eigentliche Arbeit macht (Text anzeigen, umbrechen, suchen usw.) und das wiederum dann doch wieder in C oder C++ geschrieben ist. (Auch der PB-Editor arbeitet mit diesem Scintilla-Control.)

Habe ich schon nach 3 Tagen die Grenzen der Möglichkeiten von PureBasic gefunden, oder habe ich was Wesentliches übersehen?

Wäre dankbar, wenn mich jemand aufklären könnte. Hoffentlich dahingehend, daß die zweite Möglichkeit zutrifft.

Suche mal nach EditorGadget und Scintilla im Forum....

also, vorhandene Gadgets zu nutzen ist eigentlich eine übliche vorgehensweise.
und die meisten Programmiersprachen benutzen kommunikation mittels API,
um etwas auf fenstern anzuzeigen, keine Anwendung, die Fenster benutzt,
schreibt etwas direkt in die Grafik-RAM.

Natürlich kannst du auch in PB im Fenstermode Tasten direkt abfragen,
natürlich musst du dafür auf API zurückgreifen,
dafür sind keine Wrapper implementiert, da die meisten nunmal Gadgets benutzen.

wenn du dann deine tastencodes bekommen hast, und gecheckt hast,
ob dein Fenster wirklich den Fokus hat,
kannst du alles wunderbar in einem Tastaturpuffer verwalten und in einem riesen-array, wo dein text drinsteht.
und das bringst du dann mittels DirectDraw, nämlich mit dem befehl DrawText() auf dein fensterle, ist gar kein thema.
solltest aber pfiffig proggen können, damit du die performance nicht killst.

PS:
dass du dafür keine Beispiele gefunden hast, liegt daran, dass es eben ein Editor-Gadget gibt,
und die meisten keinen Bock haben, trotzdem eins selber zu proggen.
das heißt nicht, dass es nicht geht.

Mit den PureBasic eigenen Befehlen wirst du hier in der Tat nicht
weit kommen. Aber mit der PureBasic Vollversion kannst du auch
bequem die WinApi benutzen. Damit lassen sich dann solche Projekte
realisieren. So leicht wie mit den PureBasic Befehlen wird das allerdings
nicht.

Mit der Demo kannst du zwar auch API benutzen , musst aber alles
selber deklarieren.

yo, genau.

wie ich sagte, nicht die komplette API hat nen PB-Wrapper bekommen,
und auch in Lösungen aus anderen Programmiersprachen wird API verwendet.

(hab ich überlesen, dass er die Demo hat?)

Kaeru Gaman hat geschrieben:also, vorhandene Gadgets zu nutzen ist eigentlich eine übliche vorgehensweise.

Das stelle ich nicht in Frage; das mache ich auch so. Nur wenn das Gadget nicht das macht, was man möchte - dann bleibt einem nichts anders übrig, als selbst Hand anzulegen, nich' wahr?

und die meisten Programmiersprachen benutzen kommunikation mittels API,
um etwas auf fenstern anzuzeigen, keine Anwendung, die Fenster benutzt,
schreibt etwas direkt in die Grafik-RAM.

Nein, das will ich auch nicht.

Natürlich kannst du auch in PB im Fenstermode Tasten direkt abfragen,
natürlich musst du dafür auf API zurückgreifen,
dafür sind keine Wrapper implementiert, da die meisten nunmal Gadgets benutzen.

wenn du dann deine tastencodes bekommen hast, und gecheckt hast,
ob dein Fenster wirklich den Fokus hat,
kannst du alles wunderbar in einem Tastaturpuffer verwalten und in einem riesen-array, wo dein text drinsteht.
und das bringst du dann mittels DirectDraw, nämlich mit dem befehl DrawText() auf dein fensterle, ist gar kein thema.
solltest aber pfiffig proggen können, damit du die performance nicht killst.

Will ich mir mal vornehmen für kalte Winterabende...

Ich hab schon mal eine Textverarbeitung programmiert, unter DOS noch (aber auch da nix direkt in RAMs geschrieben), und während der Arbeit daran hat mein Respekt vor den Programmierern von, sagen wir, WinWord durchaus zugenommen... Hab's letztlich aber hingekriegt, und nun würde ich das eben gerne in Windows haben. Ich umgebe mich gerne mit Programmen, bei denen ich jedes Byte persönlich kenne. Und bei denen ich, wenn ich was ändern will, direkt ins Gekröse greifen kann...

dass du dafür keine Beispiele gefunden hast, liegt daran, dass es eben ein Editor-Gadget gibt,
und die meisten keinen Bock haben, trotzdem eins selber zu proggen.
das heißt nicht, dass es nicht geht.

Hmm, ich glaube, das ist mir aus der Demo nicht voll klar geworden, daß ich die gesamte Windows-API nutzen kann. Das würde schon helfen. Ich will das bloß nicht in C-Spaghetti eingewickelt managen müssen; da ist mir 'ne Sprache wie PureBasic lieber.

Danke für die Aufmunterung! Ich geh dann mal bestellen...

edel hat geschrieben:Mit den PureBasic eigenen Befehlen wirst du hier in der Tat nicht
weit kommen. Aber mit der PureBasic Vollversion kannst du auch
bequem die WinApi benutzen. Damit lassen sich dann solche Projekte
realisieren. So leicht wie mit den PureBasic Befehlen wird das allerdings
nicht.

Schon klar. Muß es auch nicht.

Mit der Demo kannst du zwar auch API benutzen , musst aber alles
selber deklarieren.

Ah ja? Sie erklärt jedesmal beim Starten, daß genau das eben nicht gehe... Was meinst Du mit "selber deklarieren"?

Openlibrary[...]
GetFunktion[...]
Callfunctionfast[...] (oder prototyp)

Damit kannst du dann auch die Funktionen aus der DLL aufrufen.
Etwas umstaendlich aber dafuer ist es ja auch nur eine Demo.

textfreak hat geschrieben:Ich hab schon mal eine Textverarbeitung programmiert, unter DOS noch (aber auch da nix direkt in RAMs geschrieben), und während der Arbeit daran hat mein Respekt vor den Programmierern von, sagen wir, WinWord durchaus zugenommen...

na siehste, dann biste ja kein Skriptkiddie, sondern eher einer der älteren Tierarten...

seit der komplett integrierten WIN-oberfläche mit ihren ganzen Handles läuft das nunmal etwas anders,
als in alten zeiten, als man noch die CPU an den Zügeln gepackt hat,
und direkt auf ihr durch den Speicherwald geritten ist.

hat Nachteile für alte Hasen, hat aber auch vorteile, und davon ab:
es lässt sich nicht ändern.

PB ist gewiss keine professionell etablierte Programmiersprache,
aber es ist eines der besten und bequemsten Werkzeuge, die mir seit langem begegnet sind.

damit meine ich vornehmlich den Game-Sektor, das war mir in VB komplett versagt ohne spezielle SDK,
aber auch auf dem Anwendungssektor hat sie viel zu bieten,
und die Möglichkeiten, die nicht integriert sind, werden zumindest nicht blockiert.

auf alle Fälle überzeugt dieses Preis-Leistung-Verhältnis,
auch aufgrund der Community, die wir haben.

Vollzugriff auf die API und deren Strukturen. Somit Betriebssystem nahes Programmieren möglich.
Dienste, Server und Client Applikationen, ODBC, GUI, etc.

Ein Compiler der "nicht" aus irgendwelchen wilden Objekten und deren Eigenschaften etwas megamäßige zuzusammenbastelt.

Fazit:
Genau das richtige für Leute aus der alten Schule, wo Objektprogrammierung noch garnicht gab.

P.S.
DCOM, COM und OCX Objektprogrammierung ist natürlich auch möglich. Nur etwas aufwändiger. Dafür hat man es aber danach verstanden.

FF