Beiträge von H.Brill

    Naja, ist halt auch Geschmackssache. Ich finde es so, wie es jetzt aussieht schon ganz gut.

    Kann sich ja jeder mit LibreOffice soformatieren, wie er es möchte.

    Danke jedenfalls fürs Lesen. Mir ist der Inhalt wichtiger, halt daß es jeder versteht.

    Könnte ja sein, daß ich eine Textpassage etwas anders formulieren soll.

    Mit den Schriften bin ich noch dran. Ich hatte die .pdf von einem Online-Konverter erstellen lassen. Da geht dann ein Editieren bzw. Ändern nicht. Offline finde ich im Moment nichts, mit dem man sowas machen kann. Der Acrobat-Reader ist ja mittlerweile auch ziemlich beschnitten worden.

    Vielleicht hat ja jemand einen Tipp für so ein Tool.

    Ich stelle mir vor, den Quellcode etwas größer, schön fett und farbig (vlt. XProfan-Blau 8-)) zu machen.

    Vielleicht als Fortsetzung zu meinem Kurs, basierend auf dem letzten Programm.

    Man gerät ja mit einfachen Textdateien als Datenbank schnell an die Grenzen. Nicht wegen der Menge Datensätze, sondern vielmehr, wenn es um zugehörige Listen zu einem Datensatz geht. Hier mal ein Code für Anfänger, der die dBase-Funktionen und ein Memo-Feld benutzt.

    Ja, so findet man ab und an solche Ungereimtheiten. Das wäre sowas, was RGH interessieren könnte.

    Es ist halt schade, daß RGH nicht mehr antwortet. Ob er es nicht mehr kann oder will, ist eine andere Sache.

    Habs gerade mal nachgelesen. Genauso ist es. Da steht zuerst eine 60 Bytes lange Struktur, wo u. a. auch der Fontname drinsteht. Aber hinten dran steht der nochmals, aber mit einem Nullbyte am Ende. So ist es dann einfacher, mit Rolands Code, den Namen von dort an (Offset 60) auszulesen.

    Ja, das steht in der Rubrik Bereiche :

    Zitat

    Die Adresse einer Bereichsvariablen kann einem Pointer zugewiesen werden und umgekehrt:

    Declare Memory Bereich, Pointer Wert

    Wert = Bereich

    Bereich = Wert

    (Gefährlich! Kann zum Systemabsturz mit Datenverlust führen!)

    Aber, was mir noch nicht so recht bei der Enum-Funktion einleuchtet :

    Code
    Font$ = String$(LogFont&, 60)

    Warum wird da erst ab Offset 60 eingelesen ? Bei Offset 0 funktioniert es ja nicht.

    Dann noch eine Frage hinterher, was die Callback-Funktionen betrifft :

    Da wird ja LogFont& als numerische Variable übergeben und jedesmal bei Fund mit ~EnumFontFamilies an die Adresse von LogFont&

    der Fontname geschrieben. Da wird ja auch nichts von uns (Anwenderseite) vorher gedimmt.

    Naja, ganz so unüblich scheint es ja nicht zu sein (siehe Hilfe)

    Hallo, habe hier noch was gefunden, das unbedingt (auch in der Profanhilfe) Erwähnung finden sollte.

    Es ist zwar jetzt nicht unbedingt ein Bug, aber man sollte es trotzdem mal wissen. :

    Zitat

    Addr(VAR)

    Hinweis: Diese Funktion kann nur die Adressen von deklarierten Variablen ermitteln

    Mein Code hierzu :

    Code
    declare a$, b%
    'a$ = " "
    Print Addr(a$)
    Print Addr(b%)
    waitkey

    Das stimmt ja nur teilweise. Während bei numerischen Variablen immer eine Adresse nach dem Deklarieren

    ermittelt werden kann, ist das bei Stringvariablen aber nicht so. Erst, wenn man ihnen einen gültigen Wert zuweist,

    kann die Adresse bestimmt werden. Das sollte man besonders bei API-Funktionen oder fremden DLLs im Hinterkopf haben.

    Warum das so ist, ist darauf zurückzuführen, daß eine numerische Variable eine feste Größe von 4 Bytes hat, während eine

    Stringvariable dynamisch ist und damit erst nach Belegung die Speicheradresse errechnet und ermittelt werden kann.

    Warum sind die Ressourcenbereiche von den Tagen und Monaten in der Profan-Ressource um 3 Stellen verschoben ? Und der Dezember steht woanders.

    Laut ResHacker stehen die mal so drin :

    Sowas könnte man ja auch nutzen, um nicht händisch schreiben zu müssen.

    Na dann mal

    Frohe Ostern !

    Bin jetzt ein gutes Stück weiter gekommen. Wenn man in die Icon Group einen neuen Eintrag schreibt, so kommt dieser auch automatisch in die Gruppe der Icons.

    Mit

    Code
    AddRess %HInstance, 14

    kann ich mir die Icon Group in die interne Listboxliste laden. Da kann man schön mit SubStr$(GetString$(0, &LOOP), 2, "|") die Namen und mit SubStr$(GetString$(0, &LOOP), 3, "|") die Sprache rausfiltern. Jetzt wird es möglich, in einer Zählschleife und den Ressourcenfunktionen alle Icons in einem Rutsch oder je nach Bedarf auszutauschen. Anbei schon mal eine Gridbox mit Checkboxen und Icons. Den Code hatte ich bei XProfan.net gefunden und für mich abgeändert :

    Ist schon mal ein Anfang.

    So, habe jetzt mal probiert. Aber erfolglos. Die Icons werden zwar als Gruppe angelegt (ResType 3 oder 14), aber im ResHacker nicht angezeigt. Probeweise habe ich mal die Leer32.dll genommen. Müßte ja im Moment egal sein, bevor ich die Originale verändere.

    Da gibt es auch 2 Bereiche : Icon + Icon Group

    Vielleicht kommt ja einer von euch da weiter.

    XProfan hat ja die 21 eingebauten Icons. Was mir auffiel : In Profan11.2a werden sie so angezeigt, wie auch in der Hilfe abgebildet. Aber in Version X4 sehen manche anders aus. Seit den X-Versionen scheint das geändert worden zu sein. Die von 11.2a würden mir da auch besser gefallen. Der Drucker ist schöner, auch der Mülleimer und das Gesicht.

    Statt nun mit dem ResHacker da mühselig auszutauschen, müßte ich mal probieren,ob das mit den neuen Ressourcenfunktionen (X4) besser geht. Da gehe ich morgen mal dran.

    Warum Roland die damals wohl ausgetauscht hat ?

    Danke auch für die Erklärung. Muß man ja erst mal drauf kommen.

    Ich hatte jetzt gedacht, nach einem CLS oder Window .... - Befehl kann man ja auch normal schreiben, Controls erstellen, malen usw. StartPaint biegt die Ausgabe dann auf den DC um und übernimmt auch alle Einstellungen, die den vorigen DC betreffen. Also, daß z.b. UseFont global (für alle DCs) wirkt.

    Wieso wirkt denn UseFont im zweiten generierten Fenster (win2) auch ? Das sind doch zwei mit API generierte Fenster und müßten doch auch verschiedene HDCs haben ? UseFont wurde doch nur im ersten StartPaint verwendet.

    Ist ja ein interessantes Thema.

    Ich denke mal, daß es da bei Delphi, das ja das XProfan compilert hat, hängt. Das ist ja auch nur bis zu einer bestimmten (aktuellen) Prozessor-Generation optimiert und vorrausschauen, was da noch für Prozessoren kommen werden, können die Entwickler von Delphi ja auch nicht. Und Roland wird auch nicht die neueste Delphiversion benutzt haben. Die sind ja nicht gerade billig.

    Aber wie auch immer, mindestens genauso schnell, wie auf einer früheren oder vorherigen Prozessor-Generation, sollten die Programme schon laufen. Das wäre ja sonst ein Rückschritt bei der gesamten Software-Industrie, nicht nur bei XProfan bzw. Delphi.

    Ich hatte damals so eine Textdatei mit US - Zipcodes (ähnlich unserer Postleitzahlen) mit etwas mehr als 10000 Einträgen. Damals war es halt schwierig, etwas zu mit so vielen Datensätzen zu finden. Das Suchen mit Profan dauerte damals gute 10 Sekunden. Als dann der Pentium rauskam, war das in etwa 3-4 Sekunden erledigt. Das waren damals Welten.

    Hallo,

    Ich kenne jemand (wohnt allerdings weit weg), der ein Gerät hat, das 9 Datenbits (N, 9, 1) sendet und empfängt. Die üblichen Terminalprogramme scheitern bei ihm jedoch und bringen Datenmüll. Jetzt habe ich das mal softwaremäßig mit comOcom ausprobiert.

    Da scheint das ja zu gehen. Aber wie sieht das jedoch mit echter Hardware aus ? Leider habe ich nichts dergleichen und hinfahren kann ich auch nicht. Bevor ich jetzt da rumprobiere : Hat da jemand schon Erfahrungen mit N, 9, 1 und echter Hardware gemacht ?

    Da die Tage so langsam wärmer werden und der Sommer näher rückt, hat so mancher wieder Sehnsucht nach Sommer, Sonne, Strand und Meer.

    Viel Spaß ! 🤩