Beiträge von RGH

    Hallo,


    wenn Du Profan2CPP mit folgender Aufrufzeile in das Benutzermenü von XProfed einbindest, kann du mit einem Klick Profan2CPP für den aktuellen Quellcode aufrufen und die EXE landet genau da, wo der Quellcode steht:

    F:\ENTW\prof2cpp\Profan2Cpp.exe -f ":D" -d ":P" :!


    Den Pfad zu Profan2CPP musst Du natürlich an Deine Gegebenheiten anpassen.


    Gruß
    Roland

    Ach so, das gibt es in XProfan doch auch. Schau mal in der Hilfe unter "Einführung: 17.3 - Binäre Dateien". Mit OpenRW wird eine Datei geöffnet un man kann auf jedes beliebige Byte der Datei zugreifen:


    Mit SEEK positionierst Du den Dateizeiger auf eine beliebige Position und mit GETBYTE, GETWORD, GETLONG oder GETCHAR$ liest Du Bytes, Words, Longints oder Strings aus der Datei. Mit den entsprechenden PUT-Befehlen kannst Du in die Datei an jede beliebige Position schreiben und mit BLOCKREAD und BLOCKWRITE kannst Du komplette Strukturen lesen und schreiben.


    Die Syntax ist zwar anders als in Basic, da ich mich hier eher an Pascal orientiert habe, aber es ist alles möglich, wasauch unter Basic möglich war.


    Gruß
    Roland

    [LEFT]Hallo,


    und noch einige zusätzliche Hintergrund-Infos! ;)


    Warum gibt es XProfan?


    "Profan" steht als Wortspiel einerseits für "Programmieren für Anwender" und andererseits für das griechische Wort für "einfach" oder "gewöhnlich" im Gegensatz zu "heilig".
    1991/92 war die Windowsprogrammierung noch sehr kompliziert. Es gab einige wenige, eher akademisch eingesetzten, objektorientierten Programmiersysteme und für die Mehrzahl der Programmierer eben C und etwas später Turbo Pascal für Windows. Und um damit z.B. ein Fenster zu erzeugen, auf dem eine Linie gezeichnet wurde, brauchte es mehrere Seiten Code: Die Windowsroutine war zu schreiben, die Messageverwaltung, etc. und um die Linie zu zeichen mußte erst ein Devicekontext erzeugt werden, dann Brush und Pen definiert werden ... und wenn man dann eine Linie auf dem Fenster sah und es bewegte, war sie sofort wieder verschwunden. Das Neuzeichnen bei Veränderung des Fensters gehtr natürlich nicht von alleine, denn das Programm bekommt von Windows nur per Message mitgeteilt, dass es neu gezeichnet werden sollte. Das Programm muß also diese Message abfragen und das Neuzeichnen dann übernehmen ...


    Von Turbo Basic und Turbo Pascal her kommend,sagte ich mir: Das muß einfacher gehen. So wie ehedem bei BASIC: Ein CLS und anschließend ein LINE. Um den ganzen Rest muß sich der Programmierer nicht kümmern müssen. Und Mitte 1992 ging es einfacher. Profan 1.3/1.4 wurde von mir als Shareware frei gegeben.


    Für was ist XProfan geeignet?


    XProfan ist geeignet für die Programmierung von alle Arten von Anwendungen, wobei ich dazu natürlich auch Spiele zähle. Da XProfan ursprünglich plattformübergreifend gedacht war (es existieren in der Tat auch ältere textbasierte Versionen für DOS, OS/2 und Linux), erzeugt der Compiler einen Zwischencode, der von der jeweiligen zum System passenden Runtime (heute spricht man da eher von Virtual Machine) abgearbeitet wird. (Ähnlich machte es früher auch Visual Basic und immer noch Java.) Auch wenn XPreofan im Laufe der Entwicklung oftmals beschleunigt wurde, kommt es von der Geschwindigkeit doch nicht immer an Delphi oder C++ heran. Manches wird allerdings dadurch wett gemacht, dass seitenlanger C++-Quelltext in XProfan oftmals nur wenige Zeilen benötigt.
    Vieles, was in anderen Sprachen durch externe Bibliotheken möglich wird, kann XProfan schon in der "Grundausstattung": Embedded SQL, dBase-Dateien, FTP und eMails senden und vor allem seit XProfan 10 OpenGL! Und besonders hier macht XProfan die Sache wieder richtig einfach: was in
    anderen Sprachen über seitenweisen Code möglich ist, schafft das XProfan-OpenGL in wenigen Zeilen! Schaut Euch nur mal den OpenGL-Kurs in der Hilfe an und vergleicht es selbst! (Die aktuelle Hilfe kann hier geladen werden: http://www.xprofan.de/download/prfchm.zip )


    Ach ja: Ein fertiges XProfan-Programm ist in der Regel eine EXE, die oft noch auf eine dieser historischen Disketten passen würde und benötigt keine weiteren mehre zig Megabyte schweren Laufzeitbibliotheken wie etwa die VB-Runtime oder die NET-Unterstützung, um zu funktionieren ... und das sogar noch auf dem uralten Windows 95!


    Das Einbinden der Windows-API ist auch kein Problem. Gerade in XProfan 11 wurde das noch einmal vereinfacht. Selbst APIs, die CallBack-Adressen erwarten, können genutzt werden und das auch im Interpreter, also im Batchbetrieb. (Dafür sind die CallBack-Funktionen in XProfan geschaffen worden und dafür funktionieren sie auch perfekt.)


    Es gibt auf dem Markt zahlreiche Spiele und Anwendungen, die in Profan² (Version 2 - 7) oder XProfan (ab Version 8) programmiert wurden. Ich weiß z.B. von einem kompletten Warenwirtschaftssystemin XProfan und auch meine Kundenverwaltung habe zu großen Teilen von Clipper nach XProfan portiert. Was kommerzielle Spiele betrifft, fällt mein Auge gerade auf die Packungen von "Robo Challenge XL" (läuft ohne Patch nur unter Win 9x/ME) und die Aufbausimulation "Die Smaragdmine". (Ein paar einfachere Spiele sind auf der XProfan CD mit dabei.)


    Für was ist XProfan nicht geeignet?


    XProfan nimmt dem Programmierer eine ganze Menge ab. Daher hat XProfan ein eigenes internes Messagehandling und eigene Fensterroutinen für die in XProfan möglichen Fensterklassen. Dieses kollidiert natürlicherweise mit sehr systemnaher Programmierung, wie sie für Dienste, manche Überwachungstools, virenähnliche Programme, etc. nötig wären. Hier hat Andreas (AHT) also recht, wenn er feststellt, dass XProfan für die Programmierung von bestimmten speziellen Systemtools ungeeignet ist. Wer so etwas möchte, findet aber das was er sucht bei C/C++ (da gibt es eine Reihe freier Compiler) und Assembler. (Auch von Delphi mit OWL würde ich da aus eigener Erfahrung abraten, aber das gehört nicht hierher ...) Es gibt zwar eine Funktion, um das XProfan-eigene Messagehandling weitgehend abzuschalten, aber gänzlich abgeschaltet wird es dadurch auch nicht. Ebenso führt die Verwendung der Prozeduradressen für etwas anderes als die genannten Callbacks zwangsläufig zu Problemen. Wenn man diese Grenzen kennt und damit umzugehen weiß, kann man trotzdem das eine oder andere auch in XProfan verwirklichen, besonders wenn man zusätzlich Assemblerroutinen (etwa mit Franks XProfan Inline Assempler XPIA) oder DLLs einbindet.


    Und weiter?


    Wer es ausprobieren will, findet hier ( PROFAN Download ) ja genügend Möglichkeiten. Wer die beste OpenGL-fähige Batchsprache für Windows nutzen will, sollte zu XProfanFree greifen, der künftige Anwendungsprogrammierer wählt die Freeware-Vollversion XProfan 9.1 und der werdende Spieleprogrammierer nimmt OGLBasic PE, den "kleinen Bruder" von XProfan.


    Gruß
    Roland


    [/LEFT]

    Zitat von Sascha Oliver Haak;677255

    Für schnelle Erfolge schätze ich das OOP. Beim zu "Fuß" programmieren ist man aber näher an der Maschine und der Grip`s wird mehr gefordert.


    Naja, so ganz kann ich diese Aussage nicht unterschreiben. Bei größeren Projekten spart man mit OOP in der Tat Zeit (sofern man es verstanden hat, was bei mir seinerzeit durchaus eine Weile gedauert hat), da Seiteneffekte bei Änderungen deutlich minimiert werden und die Wiederverwendbarkeit von Code durch Vererbung erheblich vereinfacht wird.


    Die prozedurale Programmierung bietet gerade bei kleineren Utilities eher den Vorteil, sofort mit dem Codieren loslegen zu können, während ich bei Objektorientierung mir im Vorfeld schon ausführlich Gedanken machen sollte, welche Klassen und Objekte ich benötige, wie die Vererbungshierarchie aussehen sollte und was für Eigenschaften und Methoden die Klassen benötigen. Objektorientierte Programmierung ist natürlich noch einfacher und schneller, wenn ich auf die Arbeit Anderer zurückgreifen kann, und eine umfangreiche und gut dokumentierte Klassenbibliothek vorliegt oder ich gar mir selber eine geschaffen habe.
    Ob ich nun in einer Klasse oder prozedural eine Aufgabe programmiere, macht keinen Unterschied, was den notwendigen Grips oder die "Nähe zur Maschine" betrifft. Nur wenn ich die Klasse einmal geschrieben habe, wird die weitere Verwendung einfacher.


    Gruß
    Roland

    Zitat von Frabbing;677099

    Scheint so, als würden mehr Leute klassisch programmieren. :D


    ... was sicher auch damit zusammenhängt, dass die meisten XProfaner in diesem Forum schon "alte Hasen" sind und schon in Profan²-Zeiten eingestiegen sind, als es noch keine Objektorientierung in Profan gab.* Und da der Mensch nun mal ein Gewohnheitstier ist ...


    Ich persönlich ziehe für größere Projekte inzwischen die objektorientierte Programmierung vor. (In meinem Hauptberuf programmiere ich hauptsächlich in Java und da geht es gar nicht anders.) Für kleinere schnelle Utilities für zwischendurch greife ich aber auch gerne zur prozeduralen Programmierung.


    Als jemand der mit prozeduraler Programmierung (BASIC, Turbo Pascal) "groß geworden" ist, war der Weg vom prozeduralen zum objektorientierten Denken natürlich nicht ganz einfach. Aber er hat sich gelohnt.


    XProfan bietet bewußt beide Programmier-Paradigmen an und läßt sogar die beliebige Vermischung zu.


    Gruß
    Roland


    * die Namensentwicklung von Profan zu XProfan für nicht ganz so "alte Hasen":


    PROFAN - Version 1.x: erste Versionen für Windows 3.0 (1992)
    PROFAN² - Version 2.x - 7.x (1992 - 2002): Neuentwicklung nach Festplattencrash mit Quellcodeverlust, jetzt mit Multimediafähigkeiten ab Windows 3.1 - ab 5.x auch 32-Bit-Versionen für Windows 95/NT - ab 6.6 nur noch 32-Bit-Version
    XProfan - Version 8.x - ??? (2003 - ????): Profan wird um Objektorientierung erweitert zum Extended Profan, kurz XProfan.

    Zitat von Uwe 'Pascal';674992

    ... Das würde (wieder mal) nur auf einen Kompromiss hinauslaufen; um alle Möglichkeiten nutzen zu können (ob Menü, TreeView, Tab usw.) kommt man um die Grundlagen nicht herum.
    So gesehen waren 90 % der Erweiterungen in Profan in den letzten Jahren eigentlich überflüssig :|

    SeeYou
    Pascal


    Naja, 90% scheint mir hier recht hoch gegriffen. ;)
    Aber du hast sicher recht: ein nicht unerheblicher Teil der Erweiterungen wenden sich an den Einsteiger oder Programmierer, der mit wenigen Zeilen möglichst viel erreichen will, und ermöglichen diesem Kreis mit wenig Aufwand Dinge zu programmieren, die der erfahrende API-Programmierer schon immer konnte, und sei es durch die Verwendung zusätzlicher DLLs!


    Zu den Menüs: Natürlich würde man ab XProfan 11 hier das deutlich sicherere Subclassing für Ownerdraw-Menüs benutzen. Oder man geht den Weg, den Norbert Strübli vor ca. 4 Jahren mit seiner XMenu.inc gegangen ist und schreibt sich die Windowsprozedur komplett selbst und verzichtet im Gegenzug auf viele XProfan-Annehmlichkeiten.


    Trotzdem könnte natürlich eine in XProfan direkt eingebaute Erweiterung die Geschichte erheblich vereinfachen, so dass man ganz ohne SubClassing (das für den Einsteiger auch einige Fallstricke bietet) oder ProcAddr (das für sowas eigentlich nicht gedacht ist) auskommen könnte. Tatsächlich bastele ich schon seit einer Weile an einer solchen Erweiterung, die z.B. bei den Menübefehlen einen zusätzlichen Parameter, nämlich ein Icon, erlaubt und möglicherweise über Set-Funktionen das Aussehen der Menüs steuert.


    Gruß
    Roland

    Und hier für alle Mitleser, die wissen wollen, wie man überhaupt Anwendungen für den Systemtray von Windows in XProfan programmiert, ein komplettes Beispiellisting mit TrayIcon-Menü und Bildern in demselben:


    Gruß
    Roland

    Hallo,


    was Dir noch fehlt, ist eine Routine um aus einem IconHandle eine Bitmap zu machen:

    Code
    Proc Ico2Bmp
      Parameters Icon&
      ' Weiße Bitmap in Größe 32 * 32 erzeugen
      Var IBmp& = Create("hNewPic", 32, 32, RGB(255,255,255))
      ' Auf diese Bitmap das Icon zeichnen
      StartPaint IBmp&
        DrawIcon Icon&, 0, 0
      EndPaint
      Return IBmp&
    EndProc

    Achtung: Die Bitmap hat natürlich die Größe eines Icons (32 * 32), was für eine Menübitmap meist zu groß ist. Bei meinem XP ist selbst 16 * 16 noch zu groß. Daher eine universellere Routine, die aus einem 32 * 32 Icon eine beliebig große (pardon: kleine) Bitmap erzeugt:

    Gruß
    Roland

    Hallo und Guten Abend!


    In der Hilfe kann ich zum Thema Objektorientierung in erster Linie den entsprechenden Kurd empfehlen. Den kann man auch bequem mit XProfanFree nachvollziehen.


    Was sicher noch fehlt, ist eine umfangreiche Klassenbibliothek, wie sie andere Hochsprachen in der Regel im Gepäck haben.


    Im offiziellen XProfan-Forum ( XProfan - eine einfache Programmiersprache ) hatte ich zwar schon mal die eine oder andere Klasse veröffentlicht, aber so eine recht Initialzündung war auch das wohl nicht. Für viele, die XProfan noch aus früheren Zeiten kennen, ist der Weg vom prozeduralen zum objektorientierten Denken wohl doch etwas zu steinig, um ihm zu folgen. ;) (Naja, bei mir war es anfangs auch nicht viel anders. Es ist halt eben mehr, als nur eine andere Technik.)


    Und dann habe ich noch eine angefangene Klassenbibliothek zum Thema GUI in der Schublade liegen ... Wenn ich doch mehr Zeit hätte ...


    Gruß
    Roland
    (hat ProBase 2009 beendet)

    Hallo,


    ein kurzer allererster Eindruck nach nur ca. 1 Stunde herumspielen mit Windows 7:


    Es wirkt auf mich wie ein schlankeres, schnelleres und angenehmeres Vista und könnte für mich ein Grund werden, in Erwägung zu ziehen, von XP SP 3 auf Windows 7 upzugraden. Vista selbst werde ich definitiv auslassen, genau so, wie ich auch ME und XP vor SP2 ausgelassen habe.


    Gruß
    Roland

    Hallo,


    auf meinem anderen Testrechner lief die Installation absolut rund. Und nachdem ich von NVidea die neuesten Vista-Treiber für meine Grafikkarte (FX 5200 / 128 MB) installiert hatte, klappte es auch mit Aero-Oberfläche.


    Ich vermute, dass beim vorigen (DELL-)Rechner die auf dem Motherboard integrierte Grafikkarte (über BIOS 128 MB zugewiesen) das Problem war. Werde heute Abend noch mal testen.


    Gruß
    Roland

    Hallo,


    bis zum 2. Booten läuft alles normal, aber dann ist Hängen im Schacht:


    Es erscheint noch die Schrift "Starting Windows" (Bild 21 im Installationsverlauf), dann wird der Bildschirm dunkel und oben ist nur am äußersten Rand ein dünner heller Strich. Und das war es dann. Ein erneutes Booten bringt keine Hilfe und das Starten im abgesicherten Modus nur den Hinweis, dass die Installation im abgesicherten Modus nicht beendet werden kann.


    Hat jemand eine Idee, woran das liegen könnte?


    Danke!


    Gruß
    Roland