Hallo,
Ich habe Execute zwar nie verwendet, halte es aber 'lediglich' für da einzeilige Pendant zu $Ifdef Interpreter, mit dem sich ja ganze Codeblöcke definieren lassen. Je Aufruf erspart das dann immerhin 2 Codezeilen. Das kann sich durchaus summieren...
Gruß Matthias
...gänzlich unerwähnt zwar nicht, aber nur unzureichend und über die Referenz auch nicht direkt zu finden (im Index unter Message). Ich selbst habe es nicht verwendet...
Gruss Matthias
Ja, so dachte ich mir das. Parameterübergabe 'en bloc' ist natürlich auch elegant. Und um das Ganze dann noch universell zu gestalten, könnte man ja den Namen der Funktion und das beinhaltende Modul auch gleich noch per Parameter übergeben. Oder ggf. noch andere Optionen einbauen...
Nur mal so als spontaner Gedanke... Da sich das 15er-Limit in Profan wohl nicht so ohne Weiteres umschiffen lässt, könnte man sich ggf. einen Workarround basteln, indem man den Aufruf solch einer "parameterlastigen" Funktion in eine DLL (evtl. als MemoryModul) verlagert. Man müsste dann alle Parameter häppchenweise in max. 15er-Paketen auf den Stack innerhalb der DLL packen, von dort dann wieder herunterholen und der nachfolgend aufzurufenden Funktion übergeben. Aber ob sich der Aufwand lohnt...?!
Da die GridBox nicht auf dem 'sichtbaren' Dialog, sondern auf einem separaten, internen Dialog liegt, bleibt SetDialogFont hier wirkungslos. Mit 'SetFont Grid, ...' sollte es aber klappen.
Gruß Matthias
@p.specht: Fehlerchecks kommen von den verwendeten Windows-APImodulen selbst
Das wird sicher auch überwiegend so sein, soweit es nicht die Profan-Syntax selbst betrifft. Da bleibt also wenig "Sparpotential" unterhalb von ErrorLevel 0. Mit dem, was die API zurückliefert, muß Profan intern ja trotzdem irgendwie umgehen, auch wenn es letztlich nicht zum Anwender durchgereicht wird.
Im Übrigen sehe ich das auch so, daß die Abwärtskompatibilität ein ein wesentliches Pro-Argument für XProfan ist, so reizvoll der Gedanke auch sein mag, ganze Funtionalitäten optional zu inkludieren. Und nicht nur die Möglichkeit, jede beliebige PRC (auch fremder Herkunft...Hauptsache versionskonform) mit dem Runtime-Modul zu starten, wäre damit dann passe.
Der allfällig mitgeschleppte "Rücksack" hat denn doch schon so seine Vorteile...
LVM_ENSUREVISIBLE=$1013 scrollt die letzte Zeile in den sichjtbaren Bereich:
SendMessage(gBox&,$1013,(getcount(gBox&)-1),1)
@p.specht
..."logische Zugehörigkeit" angezeigt... Genau das meinte ich im Nachtrag, nur fiel mir kein klangvoller Begriff ein 
Das funktionierte wohl auch schon damals bei Version 5 ohne besondere Erwähnung. Lt. Hilfe zu XProfan 11 aber auch offiziell: 'Die PROC-ENDPROC-Verschachtelung, und damit die Rekursionstiefe ist unbegrenzt...' Steht dort aber unter 'XProfan ohne Grenzen', wo man eher nicht danach sucht...
Nachtrag: Ob sinnvoll oder nicht ? Wenn 'proc2' lediglich eine 'Unterfunktion' von 'proc1' ist (und nur von dieser !) kann es den Code eventuell übersichtlicher machen.
Es gibt in der Tat schon was in dieser Richtung: 'Profan-Inspector' von Sebastian König. Die Entwicklung endete zwar nach Profan 11. Das Programm ist aber in gewissem Rahmen 'lernfähig', d.h. man kann auch Profan-Neuerungen einpflegen. Sehr zuverlässig in der Erkennung. Ich verwende es gern und regelmäßig.
Nun geht das, was Du vor hast, z.T. über die reine Erkennung hinaus und soll auch noch so einiges anderes können. Auf jeden Fall ein interessantes und ambitioniertes Vorhaben, das ich mir dann gern mal ansehen werde, wenn es soweit ist. Ob man es braucht (und wenn wie viele...), sei jetzt mal dahin gestellt. Sowas macht ja auch irgendwie Spass. Also gutes Gelingen...!
Das sollte für alle Eventualitäten genügen, egal, ob (eigene) EXE oder DLL:
proc Resource2File
parameters Path$,ResName&,ResType&,File$
declare ResFile&,Resource#,ResSize&,ResHdl&,Res&
''Modul laden (statt UseDLL) oder alternativ "LoadLibraryEx"
ResFile& = external("Kernel32","LoadLibraryA",addr(Path$))
Res& = external("Kernel32","FindResourceA",ResFile&,ResName&,ResType&)
ResHdl& = external("Kernel32","LoadResource",ResFile&,Res&)
ResSize& = external("Kernel32","SizeofResource",ResFile&,Res&)
''in Datei schreiben, falls gewünscht
dim Resource#,ResSize&
Resource# = ResHdl&
assign #1,File$
openrw #1
blockwrite #1,Resource#,0,ResSize&
closerw #1
dispose Resource#
''wieder freigeben (statt FreeDLL)
external("Kernel32","FreeLibrary",ResFile&)
endproc
''Bsp. ...schreibt die Manifest-Ressource in eine Textdatei
Resource2File("PROFAN.EXE",1,24,"MANIFEST.TXT")
Gruß Matthias
Hallo,
nur mal schnell zwischendurch und ohne genau zu wissen, was Du meinst...
Die Messages
TB_GetButton https://docs.microsoft.com/de-de/windows/…ls/tb-getbutton
und
TB_GetButtonInfo https://docs.microsoft.com/de-de/windows/…b-getbuttoninfo
sollten eigentlich die relevanten Infos zurückliefern. Falls Du das nicht schon probiert hast...
Gruß Matthias
Nun ja, ob sinnhaft oder nicht. Die ToolBar ist einerseits entstehungsgeschichtlich deutlich älter als die ToolTips. Und auch wenn es aus Anwendersicht vielleicht anders erscheint (erscheinen soll), gegenüber dem Betriebssystem fungiert nur die ToolBar selbst als eigenständiges Control (mit eigenem Handle und, falls gewünscht, mit ToolTip), deren Unterelemente beliebiger Anzahl hingegen nicht.
Grob vergleichbar etwa mit einer Liste, die ja auch beliebig viele Items haben kann. Für das System handlebar ist aber immer nur die Liste selbst.
Gruß Matthias
Nun, es ist einfach so, daß eine ToolBar nur jeweils ein assoziiertes ToolTip-Control hat (und nicht etwa jedes in der ToolBar enthaltene Element sein eigenes...). Folglich kann man auch nur dieses eine ToolTip-Control in seinen Eigenschaften verändern. Soweit dazu...
Willst Du also ein unterschiedliches Erscheinungsbild des ToolTips für jedes einzelne Element innerhalb der ToolBar, ginge das wohl nur, wenn Du vor jedem MouseOver bzw. jedem Neuzeichnen des ToolTips die Eigenschaften des einzig vorhandenen ToolTip-Controls der ToolBar änderst.
So jedenfalls meine Annahme, falls ich Dein Anliegen richtig verstanden habe...
Gruß Matthias
Dann erstmal Danke Euch beiden...
Dann basiert meine Info wohl auf einer veralteten Strukturdefinition. Jedenfalls haben 32bit bei mir immer ausgereicht. Wie auch immer - damit wäre auch das jetzt bereinigt.
Gruß Matthias
Da ich das heute grade selbst brauchte und hier keine Option zum Editieren des Alt-Beitrags fand:
hdi# ist mit 28 Byte doch etwas zu knapp dimensioniert...besser also 32 statt 28 Byte
Gruß Matthias
Vielleicht wäre es mal noch eine Überlegung wert, ein Flag für WS_VISIBLE als Parameter zu übergeben (zusätzlich zu den Fenster-Koordinaten). Nicht wissend, wie aufwändig das intern umzusetzen wäre...
Gruß Matthias
Na ja, sieht doch gut aus !
Vielleicht noch optionales Speichern beim Beenden...
Platz für eine entspr. CheckBox oder "Optionen"-Button wäre ja noch neben der "Hilfe".
Ansonsten gut gelungen und vor Allem schön übersichtlich !
Vielleicht noch einen Plausibilitäts-Check bspw. bei den Kontodaten, da gerade hier eventuelle Eingabefehler seeehr unangenehm sein können. Aber vlt. hast Du an sowas schon gedacht. Das viel mir aus aktuellem Anlass eben noch ein...
Gruß Matthias
Ach so...und zum Entfernen des Sortierpfeils (beim Wechsel der Spalte):
proc SetHeader_RemoveArrow
parameters LV&,column&
declare hdi#,fmt&,hdr&,txt$
hdr& = SendMessage(LV&,$101F,0,0)
txt$ = space$(255)
dim hdi#,32
long hdi#,0 = 183
long hdi#,8 = addr(txt$)
long hdi#,16 = 256
SendMessage(hdr&,$1203,column&,hdi#)
fmt& = long(hdi#,20)
if fmt& & 4096
fmt& = fmt& - 4096
endif
if fmt& & 2048
fmt& = fmt& - 2048
endif
if fmt& & 1024
fmt& = fmt& - 1024
endif
if fmt& & 512
fmt& = fmt& - 512
endif
long hdi#,20 = fmt&
SendMessage(hdr&,$1204,column&,hdi#)
dispose hdi#
endprocna dann, viel Spass.....
Die Sortierpfeile bekommst Du erstmal damit:
proc SetHeader_SetArrow ''(Par: ListView, Spalte, Sortier-Richtung)
parameters LV&,column&,updn&
declare hdi#,fmt&,hdr&,txt$
hdr& = SendMessage(LV&,$101F,0,0)
txt$ = space$(255)
dim hdi#,28
long hdi#,0 = 167
long hdi#,8 = addr(txt$)
long hdi#,16 = 256
SendMessage(hdr&,$1203,column&,hdi#)
fmt& = long(hdi#,20)
ifnot fmt& & 4096
fmt& = fmt& + 4096
endif
if (updn& = 0) | (updn& = 2)
ifnot fmt& & 1024
fmt& = fmt& + 1024
endif
elseif (updn& = 1)
ifnot fmt& & 512
fmt& = fmt& + 512
endif
endif
long hdi#,20 = fmt&
SendMessage(hdr&,$1204,column&,hdi#)
dispose hdi#
endprocDer Header-Style muß natürlich entsprechend gesetzt sein (Buttons...)
Nun brauchst Du "nur" noch Abfrage Spaltenklick, Sortierfunktion etc.
Gruß Matthias