Beiträge von Jens-Arne

Jens-Arne

Das hat mir natürlich alles wieder keine Ruhe gelassen. Ich habe mir daher den "Pfeifenwichs" (wie Dieter Hallervorden alias Kongo Otto es in "Die Rache der Enterbten" ausgedrückt hätte) mal genauer angesehen. Und es ist natürlich wieder genau das: Pfeifenwichs, also unglaublich komplizierte Windows-API-Programmierung. Aber man kann, ebenfalls wie fast immer, auch fast alles damit anstellen. Zum Beispiel Float-Werte inkrementieren, oder sogar beliebige Strings statt der Zahlen in das SpinEdit schreiben. Das ist bestimmt manchmal einfacher (bei wenigen Auswahlmöglichkeiten), als immer eine ChoiceBox aufklappen und darin herumklicken zu müssen.

Auch wenn ich den Code nachher nicht mehr ändern kann, wenn ich noch einen Fehler finde oder Verbesserungen vornehme, poste ich ihn trotzdem einmal hier:

!

Code

$H Windows.ph
$H Messages.ph
STRUCT S_NMHDR=hwndFrom&,idFrom&,code&
STRUCT S_NMUPDOWN=hwndFrom&,idFrom&,code&,iPos&,iDelta&
declare ende%,hSE%,hUD%,hSE2%,hUD2%,value%,b#,StringsForSE2$[3],AnzStringsForSE2%
SUBCLASSPROC
 declare ReturnValue&,b#,OldValue!,NewValue!,StepValue!,code&
 declare OldStringVal$,NewStringVal$,i%,val%
 ReturnValue&=0
 '{ ;%HWnd
 if &sWnd=%HWnd
   '{ 'WM_NOTIFY
   if %sMessage=~WM_NOTIFY
     dim b#,S_NMHDR
     b#=&slParam
     '{ '1. SpinEdit (Float-Werte)
     if b#.hwndfrom&=hUD%
       if b#.code&=-722 '-722=~UDN_DELTAPOS
         StepValue!=1.05
         dispose b#
         dim b#,S_NMUPDOWN
         b#=&slParam
         if b#.idelta&>0 'Up-Button clicked (CAVE: Wenn man MaxVal und MinVal falsch herum gesetzt hat, zählen die Pfeile in die falsche Richtung!)
           '@sendmessage(hUD%,~UDM_SETPOS32,0,@sendmessage(hUD%,~UDM_GETPOS32,0,0)+1) 'hier können nur Integer-Werte gesetzt werden (aber die Range-Kontrolle übernimmt dann immerhin das UpDown-Control), wir setzen das Edit-Control also vollständig selbst
           OldValue!=@val(@gettext$(hSE%))
           NewValue!=OldValue!+StepValue!
           if NewValue!<-0.0
             NewValue!=0.0
           elseif NewValue!>100.0
             NewValue!=100.0
           endif
           settext hSE%,@str$(NewValue!)
           '~beep(2000,30)
         elseif b#.iDelta&<0 'Down-Button clicked
           '@sendmessage(hUD%,~UDM_SETPOS32,0,@sendmessage(hUD%,~UDM_GETPOS32,0,0)-1) 'hier können nur Integer-Werte gesetzt werden (aber die Range-Kontrolle übernimmt dann immerhin das UpDown-Control), wir setzen das Edit-Control also vollständig selbst
           OldValue!=@val(@gettext$(hSE%))
           NewValue!=OldValue!-StepValue!
           if NewValue!<-0.0
             NewValue!=0.0
           elseif NewValue!>100.0
             NewValue!=100.0
           endif
           settext hSE%,@str$(NewValue!)
           '~beep(1000,30)
         endif
         @set("WinProc",0) 'muss sein, weil sonst auch mit return 1 immer noch Windows die Kontrolle über diese Aktion behalten würde und um 1 in-/dekrementieren würde
         ReturnValue&=1 '0=UDS_SETBUDDYINT-Style in-/dekrementiert automatisch und überschreibt unsere Änderungen (wenn er bei der Control-Erstellung gesetzt wurde), also <>0 zurückgeben ("wir machen das selbst")
       endif
     '}
     '{ '2. SpinEdit (Strings)
     elseif b#.hwndFrom&=hUD2%
       if b#.code&=-722 '-722=~UDN_DELTAPOS
         dispose b#
         dim b#,S_NMUPDOWN
         b#=&slParam
         if b#.idelta&>0 'Up-Button clicked (CAVE: Wenn man MaxVal und MinVal falsch herum gesetzt hat, zählen die Pfeile in die falsche Richtung!)
           for i%,1,AnzStringsForSE2%
             if StringsForSE2$[i%]=@gettext$(hSE2%)
               val%=i%+1
               if val%>AnzStringsForSE2%
                 val%=1
               endif
               break
             endif
           endfor 'i%
           settext hSE2%,StringsForSE2$[val%]
           '~beep(2000,30)
         elseif b#.iDelta&<0 'Down-Button clicked
           for i%,1,AnzStringsForSE2%
             if StringsForSE2$[i%]=@gettext$(hSE2%)
               val%=i%-1
               if val%<1
                 val%=AnzStringsForSE2%
               endif
               break
             endif
           endfor 'i%
           settext hSE2%,StringsForSE2$[val%]
           '~beep(1000,30)
         endif
         @set("WinProc",0) 'muss sein, weil sonst auch mit return 1 immer noch Windows die Kontrolle über diese Aktion behalten würde und um 1 in-/dekrementieren würde
         ReturnValue&=1 '0=UDS_SETBUDDYINT-Style in-/dekrementiert automatisch und überschreibt unsere Änderungen (wenn er bei der Control-Erstellung gesetzt wurde), also <>0 zurückgeben ("wir machen das selbst")
       endif
     '}
     endif
     dispose b#
   '}
   endif
 '}
 endif
 return ReturnValue&
ENDPROC
windowstyle 1+2+4+8+512
cls
usermessages $10
@set("Decimals",2)
hSE%=~CreateWindowEx(~WS_EX_CLIENTEDGE,"EDIT","",~WS_CHILD | ~WS_VISIBLE | ~ES_RIGHT | ~WS_TABSTOP,50,30,90,22,%HWnd,1,%HInstance,0) ' | ~ES_NUMBER - nein, dann können keine negativen Zahlen und keine Dezimalzahlen eingegeben werden (diese Limits könnte man entsprechend im Subclassing abfangen, wenn man wollte, aber das sprengt hier den Rahmen)
hUD%=~CreateWindowEx(0,"msctls_updown32",0,~WS_CHILD | ~WS_VISIBLE | 4 | 2 | 32,0,0,0,0,%HWnd,2,%HInstance,0) 'erstellt das UpDown-Control
'UDS_SETBUDDYINT (2) = setzt den Wert direkt im Edit-Control - wenn man andere Schrittweiten als 1 will, darf dieser Style nicht gesetzt sein (oder im Subclassing WinProc auf 0 setzen *und* <>0 zurückgeben), dann muss man mit Subclassing von hWndParent die Notification UDN_DELTAPOS auswerten und das Editfeld selbst bestücken
'UDS_ALIGNRIGHT (4) = rechts im Edit-Feld (dieses wird automatisch entsprechend verkleinert, um die Pfeil-Buttons aufzunehmen)
'UDS_ARROWKEYS (32) = das UpDown-Control verarbeitet die hoch-/runter-Tasten, wenn der Fokus auf dem verknüpften Edit-Control liegt (es wird dadurch UDN_DELTAPOS ausgelöst, genau wie bei Mausklicks auf die Pfeilbuttons)
'UDS_SETBUDDYINT (16) = de-/inkrementiert das Edit-Control automatisch (hier nicht benutzt, weil wir Float-Werte benutzen wollen)
'{ 'alle UDS-Stile
/*
UDS_ALIGNLEFT
Positions the up-down control next to the left edge of the buddy window. The buddy window is moved to the right, and its width is decreased to accommodate the width of the up-down control.
UDS_ALIGNRIGHT
Positions the up-down control next to the right edge of the buddy window. The width of the buddy window is decreased to accommodate the width of the up-down control.
UDS_ARROWKEYS
Causes the up-down control to increment and decrement the position when the UP ARROW and DOWN ARROW keys are pressed.
UDS_AUTOBUDDY
Automatically selects the previous window in the z-order as the up-down control's buddy window.
UDS_HORZ
Causes the up-down control's arrows to point left and right instead of up and down.
UDS_HOTTRACK
Causes the control to exhibit "hot tracking" behavior. That is, it highlights the UP ARROW and DOWN ARROW on the control as the pointer passes over them. This style requires Windows 98 or Windows 2000. If the system is running Windows 95 or Windows NT 4.0, the flag is ignored. To check whether hot tracking is enabled, call SystemParametersInfo.
UDS_NOTHOUSANDS
Does not insert a thousands separator between every three decimal digits.
UDS_SETBUDDYINT
Causes the up-down control to set the text of the buddy window (using the WM_SETTEXT message) when the position changes. The text consists of the position formatted as a decimal or hexadecimal string.
UDS_WRAP
Causes the position to "wrap" if it is incremented or decremented beyond the ending or beginning of the range.
*/
'}
@sendmessage(hUD%,1129,hSE%,0) '1129=~UDM_SETBUDDY - verknüpft das Edit-Control mit dem UpDown-Control
@sendmessage(hUD%,1135,0,100) '1135=~UDM_SETRANGE32; Min 0, Max 100 - CAVE: Wenn man die Werte vertauscht, zählen die Pfeile falschherum (Up-Arrow: -1, Down-Arrow: +1). In diesem Beispiel überschreiben wir alle Automatismen in der SubclassProc, weil wir Float-Werte inkrementieren wollen, diese Zeile dient daher nur der Demonstration. - Nach Erstellung des UD-Controls sind die Pfeile erst einmal falsch herum gepolt!
@sendmessage(hUD%,1127,0,50) '1127=~UDM_SETPOS; Startwert - Ist hier ebenfalls nur um der Demonstration willen, da wir einen Float-Wert setzen wollen, was mit einem nativ arbeitenden SpinEdit nicht geht:
settext hSE%,"50.00"
value%=@sendmessage(hUD%,1138,0,0) '1138=~UDM_GETPOS32 - kann nur Integer-Zahlen verarbeiten!
print "Anfangswert SpinEdit Nr. 1="+@str$(value%)+" (hier falsch (Maximum), weil keine Integer-Zahl)" 'gibt hier einen falschen Wert zurück, weil im SpinEdit keine Integer-Zahl steht
subclass %HWnd,1 'müsste bei der sehr oft verwendeten Schrittweite 1 nicht sein, machen wir hier aber so, um das "volle Programm" zu demonstrieren (Float-Inkrementierung und Strings)
hSE2%=~CreateWindowEx(~WS_EX_CLIENTEDGE,"EDIT","",~WS_CHILD | ~WS_VISIBLE | ~WS_TABSTOP,50,60,120,22,%HWnd,1,%HInstance,0) ' | ~ES_RIGHT 
hUD2%=~CreateWindowEx(0,"msctls_updown32",0,~WS_CHILD | ~WS_VISIBLE | 4 | 32,0,0,0,0,%HWnd,2,%HInstance,0) 'erstellt das UpDown-Control
@sendmessage(hUD2%,1129,hSE2%,0) '1129=~UDM_SETBUDDY
@sendmessage(hUD2%,1135,0,1) '1135=~UDM_SETRANGE32; müssen wir machen, obwohl wir gar keine Zahlen verarbeiten wollen, damit die Pfeile in die richtige Richtung wirken (es kommt hier nur auf die Richtung an, die Werte an sich sind egal) - Nach Erstellung des UD-Controls sind die Pfeile erst einmal falsch herum gepolt!
AnzStringsForSE2%=3
StringsForSE2$[1]="Teststring 1"
StringsForSE2$[2]="Teststring 2"
StringsForSE2$[3]="Teststring 3"
settext hSE2%,StringsForSE2$[1]
ende%=0
whilenot ende%
 waitinput
 if @iskey(27) or (%uMessage=$10)
   ende%=1
   while @iskey(27)
     sleep 25
   endwhile
 endif
endwhile
subclass %HWnd,0
usermessages -$10
end

Alles anzeigen

Jens-Arne

Ich weiß nicht mehr, wo ich das mal gefunden hatte, aber man kann das Handle des Controls für die beiden Pfeile wie folgt herausfinden:

Code

hUDC%=@GetHandle(hW%,@ItemID(hSE%)+1) 'hW%=Handle des Dialogelements/Fensters, das das Spinedit enthält; hSE%=Handle des Spinedits

Man muss dann die Fensteraktionen (SetWindowPos, ShowWindow, DestroyWindow etc.) auch auf dieses Control anwenden, dann bleibt alles konsistent.
Das Up-Down-Control sitzt @Width(hSE%)+4 Pixel weiter rechts als das SpinEdit.

Jens-Arne

In der Hoffnung, dass Roland hier noch mitliest und irgendwann vielleicht doch nochmal irgendwann, eines Tages ein Patch kommt: Ich habe das TrayIcon-Problem unter Windows 11 bei verborgenen Hauptfenstern gelöst. Das lässt sich sicher auch einfach in den XProfan-Code integrieren.

Siehe hier: https://xprofan.net/intl/de/forum/trayicon-msg-windows-11/

Beste Grüße, ein frohes Fest und einen guten Rutsch,
Jens-Arne

Jens-Arne

Hallo,

ich meine mich zu erinnern, dass XProfan den Fensterinhalt aus %HDC2 wiederherstellt, wenn er durch irgendeine Aktion überschrieben wird (also vermutlich immer dann, wenn das System ein WM_PAINT auslöst). Durch das CLS scheint irgendwie auch der BkMode der beiden DCs zurückgesetzt zu werden. Wenn man das so wie hier drunter ersichtlich macht, funktioniert es offenbar bei allen denkbaren Fensteränderungen:

Code

$H windows.ph
Declare Int Zahl
CLS
'TextColor 0, -1
While 1
  CLS RGB(196, 196, 188)
  ~SetBkMode(%HDC,~TRANSPARENT) 'das ist nichts anderes als -1 als 2. Parameter bei TextColor
  ~SetBkMode(%HDC2,~TRANSPARENT)
  DrawText 4, 4, "Ein Test " + Str$(Zahl)
  Inc Zahl
  WaitInput
EndWhile

Alles anzeigen

Es kann aber auch sein, dass im DC2 aus irgendwelchen Gründen immer der BkMode zurückgesetzt wird, so ganz bin ich da noch nicht durchgestiegen.

Jens-Arne

Hallo,

die Funktion @rnd() von XProfan generiert eine Pseudo-Zufallszahl, die allerdings für kryptographische Anwendungen unbrauchbar ist. Das gilt schon für die deterministische Natur des Generators an sich, insbesondere aber dafür, dass @set("randseed",x) nur 65535 Startwerte zulässt, was nach heutigen Maßstäben geradezu lächerlich wenig ist. Schon dass Seeden eines PRNG nur mit dem vollen Long-Wert der Millisekunden seit dem letzten Systemstart gilt als sträflich nachlässig.

Moderne Windows-Systeme bringen eine API-Funktion mit, die hier Abhilfe schafft. Zum Beispiel, wenn man sichere Passwörter aus echten Zufallszahlen generieren möchte. Fast jede moderne CPU besitzt einen "Noise-Chip", der echte Zufallszahlen generiert. Hierauf greift die Windows-Funktion zu, und wohl auch noch auf andere Entropiequellen aus dem System.

Hier die XProfan-Funktion, um hieraus eine echte Zufallszahl zu generieren:

Code

PROC GetSystemRandomNumber 'generiert eine Byte-Zufallszahl zwischen 0 und endnumber&-1 über den Windows-Zufallszahlengenerator (Rückgabe von -1=Fehler)
  parameters endnumber&
  declare b#,erg&,r&,f!
  if %pcount=0
    endnumber&=256
  endif
  if endnumber&>256
    endnumber&=256
  elseif endnumber&<2
    endnumber&=2
  endif
  dim b#,2 'muss ein Word fassen, siehe unten
  erg&=@external("Bcrypt.dll","BCryptGenRandom",0,b#,2,2) 'letzter Parameter: 2=~BCRYPT_USE_SYSTEM_PREFERRED_RNG; vorletzter Parameter=Puffergröße, weist die Funktion an, zwei Zufalls-Bytes (also ein Zufalls-Word) zurückzugeben
  if erg&<>0 'Fehler
    r&=-1
  else
    if endnumber&=256
      'direkt erste generierte Zufallszahl zwischen 0 und 255 übernehmen
      r&=@byte(b#,0)
    else
      'generierte Zufallszahl zwischen 0 und 65535 auf Bereich zwischen 0 und endnumber&-1 mappen
      'hierzu brauchen wir ein Zufalls-Word, weil bei einem Byte bei bestimmten Endnumbers manche Zahlen deutlich bevorzugt würden, weil mindestens eine mehr aus dem 255er-Feld nach dem Int zu ihnen werden als bei anderen Zahlen
      'das hingegen ist bei 65535 Zahlen, die auf maximal 0-254 gemappt werden, zu vernachlässigen
      'ein Long wiederum wäre grundsätzlich noch besser, geht aber nicht, weil es in XProfan signed ist, wir aber nur positive Zahlen erhalten wollen (mit Quad ab XProfan X2 ist es dasselbe)
      r&=@word(b#,0)
      while r&=$FFFF 'nicht $FFFF, weil dann das Ergebnis =endnumber& wäre, nicht kleiner --> also neue Zufallszahl generieren
        erg&=@external("Bcrypt.dll","BCryptGenRandom",0,b#,2,2)
        if erg&<>0 'Fehler
          r&=-1
          break
        else
          r&=@word(b#,0)
        endif
      endwhile
      if r&<>-1
        f!=r&/$FFFF
        f!=f!*endnumber&
        r&=@int(f!)
      endif
    endif
  endif
  dispose b#
  return r&
ENDPROC 'GetSystemRandomNumber

Alles anzeigen

Beste Grüße, Jens-Arne

Wer's noch individueller und unabhängig vom System und von Microsoft haben will (nur Rezept, kein Code):

- Foto mit viel Entropie aufnehmen (z.B. Baumlaub im Wind)
- hieraus, sagen wir, 10000 Farbwerte nehmen (enthält reichlich genug Entropie)
- über den Speicherbereich, in dem diese Werte stehen, den SHA256-Algorithmus laufen lassen
- schon hat man 32 exzellente echte Zufallsbytes an der Hand
- ggf. mit den nächsten 10000 Farbwerten wiederholen etc. pp.
- Foto sofort löschen (es soll ja niemand sonst den Seed der Zufallszahlen kennen)

Jens-Arne

Das funktioniert allerdings nicht so richtig automatisiert, weil man diese API-Funktion nach jeder Änderung der Inhalte für jede Spalte, die betroffen ist, erneut aufrufen muss. Das kann bei sehr vielen Gridbox-Einträgen und/oder -Spalten auch ganz schön lange dauern. Vielleicht wäre aber eine Aufnahme dieser Möglichkeit über die API in die XProfan-Hilfe nicht verkehrt.

Jens-Arne

Hallo Heinz,

wenn es um die Breite der Spalten der Gridbox geht, dann kannst Du die mit

Code

declare integer i
for i,0,3 'muss für jede Spalte einzeln geschehen
   @sendmessage(grid,4126,i,-2) '4126=~LVM_SETCOLUMNWIDTH; -2=~LVSCW_AUTOSIZE_USEHEADER stellt die Spaltenbreite anhand der Überschrift ein; mit -1=~LVSCW_AUTOSIZE wird sie anhand der Daten bestimmt
endfor 'i

automatisch einstellen lassen. Muss nach

Code

db("slSQLExec", mydb, "SELECT * from KUNDEN", grid)

stehen.

Beste Grüße, Jens-Arne

Jens-Arne

Stimmt, das ist deutlich eleganter (und schneller).

Jens-Arne

Du musst $FF000000 abziehen. Dann erhältst Du den Wert mit den drei Bytes. Allerdings nur, wenn die höchstwertigen Bytes $FF sind, sonst das, was sie sind.

Genereller Code:

Code

a%=$FFAABBCC
b%=a%-(@byte(@addr(a%),3) << (4*6))

Jens-Arne

Das müsste so gehen. Das Bild in die Memory-Bitmap laden, StartPaint -1 und dann sollte GetPixel eigentlich darauf zugreifen. - Ja, geht:

Code

Declare x%,y%
Cls
MLoadBmp "test.png"
StartPaint -1
For y%,0,%BmpY-1
  For x%,0,%BmpX-1
    'print @GetPixel(x%,y%) 'hier kann der Farbwert in eine Datei geschrieben werden
  EndFor 'y%
EndFor 'y%
EndPaint
End

Alles anzeigen

Allerdings ist dabei zu beachten, dass GetPixel extrem langsam ist, ebenso wie SetPixel. Das ist kein Bug von XProfan, sondern Windows-bedingt.

Wenn man derartige Operationen schnell ausführen möchte, sind extreme Klimmzüge erforderlich. Man muss das Bild erst einmal mit API-Funktionen in einen verständlichen Speicherbereich schreiben, daran dann Manipulationen durchführen und das ganze hinterher wieder in eine DIB (device independent bitmap) zurückverwandeln, um das Ergebnis ggf. anzeigen oder in einem gängigen Bildformat speichern zu können. Das ist hier allerdings nicht unbedingt nötig, weil 60x60 Pixel noch in einer erträglichen Geschwindigkeit abgearbeitet werden. Bei heute gängigen Fotos ist GetPixel aber völlig unbrauchbar.

Da der Ursprungspost "...und weitere PNG..." beinhaltet, steht zu befürchten, dass die nicht alle so klein sind. Da könnte dann z.B. die Bibliothek FreeImage (https://freeimage.sourceforge.io/) weiterhelfen. Da muss man sich aber ziemlich reinfuchsen. Damit ist es möglich, die Pixel in einem zugänglichen Speicherbereich zu erhalten. Man muss dann aber immer noch einige Dinge beachten, z.B. dass die Zeilen auf ein LongInt gepadded sind und dass viele Bildformate "falschherum" (unterste Zeile zuerst) abgelegt sind.

Jens-Arne

Ja, das ist in diesem Fall tatsächlich der viel einfachere Weg, ich seh's ein. Und vermutlich sowieso der einzige, der zum Erfolg führt.

Jens-Arne

Ich habe mal ChatGPT folgendes gefragt:

"Kannst Du mir den internen Aufbau von ROLAND-UPA-Dateien erklären?"

Was dabei herauskam, macht 1. wenig Hoffnung, dass man durch Anschauen herausbekommen kann, wie so eine Datei exakt aufgebaut ist und legt 2. nahe, dass das schon ein proprietäres Format ist, das man nicht einfach so nachbauen darf.

Ich glaube, es ist vergebene Liebesmüh', das weiter zu versuchen. Es hat schon seinen Grund, dass so ein Programm knapp 1.000 Zeilen braucht, wie Deine Quelle zu berichten wusste.

Außerdem hast Du den Riesennachteil, dass Du nicht testen kannst, was Du da fabrizierst. Dazu müsstest Du schon so ein programmierbares Akkordeon haben.

Jens-Arne

Ah, ok, sollen die kleinen Dateien jeweils auch wieder einlesbare Musikdateien ergeben? Dann reicht es natürlich nicht, die Originaldatei einfach nur auseinanderzunehmen, sondern jede neue Datei muss einen passsenden Header bekommen.

Für die Frage, ob Du das machen darfst, kommt es wohl darauf an, ob das Musikdateiformat ein freies Format dergestalt ist, dass jeder, der möchte, solche Dateien erstellen darf, oder ob das nicht der Fall ist (jeder darf z.B. MIDI-Dateien erstellen, soweit ich weiß, aber es darf nicht jeder DOC-Dateien erzeugen).

Jens-Arne

Achtung, die Datei- und Ordnerüberwachungsfunktionen der Windows-API sind notorisch unzuverlässig! Die verpassen in schöner Regelmäßigkeit geänderte, gelöschte und neu erstellte Dateien. Daran ist ein Projekt von mir gescheitert, in dem ich einen Datei-Explorer bauen wollte. Ganz sicher kann man nur sein, wenn man das Zielverzeichnis in regelmäßigen Abständen händisch überprüft, z.B. mit AddFiles.

Außerdem frage ich mich, warum Du die Datei nicht selbst auseinandernimmst (blockread --> blockwrite). Dazu brauchst Du doch kein externes Programm.

Jens-Arne

Einen herzlichen Glückwunsch an Roland zum 70. Geburtstag! Mögen viele weitere Jahre Gesundheit, Glück und Enthusiasmus seinen Lebensweg begleiten!

Jens-Arne

Hallo Heinz,

Du hast recht, das sollte auch in der Anleitung stehen. Das ist jetzt ergänzt.

Jens-Arne

Hallo Heinz,

danke für den Hinweis - aber nein, das ist kein Wrapper (habe ich im xprofan.net-Forum auch dazugeschrieben). Der würde auch gar nicht als DLL für andere Programmiersprachen funktionieren, weil das entsprechende PB-Gadget ein PB-Hauptfenster und den PB-Messageloop braucht.

Jens-Arne

Liebe Gemeinde,

in manchen Programmiersprachen (z.B. PureBasic) gibt es Controls, die als Container für andere Controls dienen. Letztere werden auf einer Oberfläche erstellt, die man danach hin- und herscrollen kann.

XProfan bringt sowas nicht mit, und auch Windows selbst hält da nichts vor.

Ich habe daher eine DLL erstellt, die diese Funktionalität bietet. Z.B. für die Anzeige von Vorschaubildern beliebiger Inhalte kann das sehr nützlich sein, aber sicher auch in anderen denkbaren Situationen.

Die DLL ist in 32bit und 64bit verfügbar. Es ist eine PDF-Anleitung und ein XProfan-Beispielprogramm beigefügt.

Die DLL kann hier heruntergeladen werden: https://xprofan.net/intl/de/dlls/scrollarea-dll

Beste Grüße, Jens-Arne

Jens-Arne

Hallo zusammen,

ich habe mal mit Themes von Windows 11 experimentiert und verschiedenen Controls jeweils ein Theme zugewiesen. Dabei kommen so lustige Sachen heraus wie eine Checkbox, die ein Pin-Symbol statt eines Kreuzchens besitzt. Aber so kann man auch wieder Checkboxen hinbekommen, die nicht blau unterlegt sind, was sie seit Windows 11 ja sind. Die Themes werden in unterschiedlichen Windows-Versionen aber vermutlich jeweils anders aussehen, sodass das vielleicht mehr eine Spielerei ist. Bzw. man müsste vor dem Setzen die jeweils laufende Windows-Version abfragen, wenn man sichergehen will, dass das so aussieht, wie man sich das vorgestellt hat.

Code

declare ende%,hBende%
declare hCB%[40],themes$[40],i%,NumThemes%,hE%[40],hB%[40],b#

window 200,200-510,850
usermessages $10
hBende%=@create("BUTTON",%HWnd,"Ende",(@width(%HWnd)/2)-100,@height(%HWnd)-40,200,30)

'{ 'Theme-Namen definieren
i%=0
inc i%:themes$[i%]="BUTTON"
inc i%:themes$[i%]="REBAR"
inc i%:themes$[i%]="TOOLBAR"
inc i%:themes$[i%]="STATUS"
inc i%:themes$[i%]="LISTVIEW"
inc i%:themes$[i%]="HEADER"
inc i%:themes$[i%]="PROGRESSBAR"
inc i%:themes$[i%]="TOOLTIP"
inc i%:themes$[i%]="TREEVIEW"
inc i%:themes$[i%]="SPIN"
inc i%:themes$[i%]="SCROLLBAR"
inc i%:themes$[i%]="EDIT"
inc i%:themes$[i%]="COMBOBOX"
inc i%:themes$[i%]="TASKBAR"
inc i%:themes$[i%]="STARTPANEL"
inc i%:themes$[i%]="EXPLORER"
inc i%:themes$[i%]="EXPLORERBAR"
inc i%:themes$[i%]="HEADERPIN"
inc i%:themes$[i%]="IEBARMENU"
inc i%:themes$[i%]="PROGRESSBARVERT"
inc i%:themes$[i%]="PROGRESSCHUNKVERT"
inc i%:themes$[i%]="TAB"
inc i%:themes$[i%]="TASKBAND"
inc i%:themes$[i%]="WINDOW"
inc i%:themes$[i%]="LINK"
inc i%:themes$[i%]="TRACKBAR"
inc i%:themes$[i%]="STATIC"
NumThemes%=i%
'}

'{ 'Dialog aufbauen
@create("TEXT",%HWnd,"Checkboxen:",10,10,150,20)
@create("TEXT",%HWnd,"Buttons:",170,10,150,20)
@create("TEXT",%HWnd,"Edit-Controls:",330,10,150,20)
for i%,1,NumThemes%
  dim b#,(@len(themes$[i%])*2)+2
  widestring b#,0=themes$[i%]
  
  hCB%[i%]=@create("CHECKBOX",%HWnd,themes$[i%],10,15+(25*(i%)),150,20)
  @external("UxTheme.dll","SetWindowTheme",hCB%[i%],0,b#)
  setcheck hCB%[i%],1
  
  hB%[i%]=@create("BUTTON",%HWnd,themes$[i%],170,15+(25*(i%)),150,20)
  @external("UxTheme.dll","SetWindowTheme",hB%[i%],0,b#)
  
  hE%[i%]=@create("EDIT",%HWnd,themes$[i%],330,15+(25*(i%)),150,20)
  @external("UxTheme.dll","SetWindowTheme",hE%[i%],0,b#)
  
  dispose b#
endfor 'i%
'}

ende%=0
whilenot ende%
  waitinput
  if @iskey(27) or (%uMessage=$10) or @clicked(hBende%)
    ende%=1
    while @iskey(27)
      sleep 25
    endwhile
  endif
endwhile

usermessages -$10
end

Alles anzeigen

Gruß, Jens-Arne

Jens-Arne

Klar geht das mit ImportDll. ich meinte, wenn man das händisch versucht, wird es extrem haarig. Und ja, wenn es eine Funktion gibt, die die DLL modifiziert, dann hat derjenige, der sie geschrieben hat, das hinbekommen. Ich würde es nur nicht nochmal selbst versuchen wollen. Zudem müsste man das ja der Vollständigkeit halber auch für 64bit-DLLs machen, und das geht vermutlich wieder ganz anders.

Beiträge von Jens-Arne

Problem mit SpinEdit

Problem mit SpinEdit

Zukunft XProfan

Zukunft XProfan

Zufallszahl über Windows-Zufallszahlengenerator

Zukunft XProfan

Zukunft XProfan

PNG Bild laden und dann die Pixel abtasten und in eine Datei Laden.

PNG Bild laden und dann die Pixel abtasten und in eine Datei Laden.

PNG Bild laden und dann die Pixel abtasten und in eine Datei Laden.

Ordner per API überwachen

Ordner per API überwachen

Ordner per API überwachen

Ordner per API überwachen

Zukunft XProfan

ScrollArea-DLL

ScrollArea-DLL

ScrollArea-DLL

Theme-Styles

Execute S