CreateWindowEx anwenden

[Andreas Vogt]

Hallo,
ich greife ein altes Problem von mir auf und möchte nach den Infos auf
der AEK einen Splitter per API realisieren.
Dazu habe ich Code aus einem Posting hier verwendet:
Dim hWin As Long
Dim WndClass As WNDCLASSEX
With WndClass
.cbSize = Len(WndClass)
.Style = CS_OWNDC Or CS_HREDRAW Or CS_VREDRAW
.lpfnWndProc = ProcAddr(AddressOf WndProc)
.cbClsExtra = 0
.cbWndExtra = 0
.hInstance = GethInstance()
.hIcon = 0
.hCursor = 0
.hbrBackground = COLOR_BTNFACE + 1
.lpszMenuName = ""
.lpszClassName = "OMain"
.hIconSm = 0
End With
RegisterClassEx WndClass
WindowClose = False
hWin = CreateWindowEx(WS_EX_OVERLAPPEDWINDOW, _
"OMain", _
"Test", _
WS_CHILDWINDOW, _
10, _
10, _
5, _
250, _
hwnd, _
0, _
GethInstance(hwnd), _
0)
ShowWindow hWin, SW_SHOW
UpdateWindow hWin

Die API Deklaration und weitere Functions hab ich mal der Übersicht
wegen weggelassen.
Ich habe jetzt mehrere Probleme. Zum einen der x-Parameter, wenn ich
den über einen Wert von ca 12 setze wird das Kindfenster nicht
sichtbar. Darunter ist das Kindfenster im Bereich des
Datensatzmarkierers sichtbar.
Ich denke da fehlt sowas wie SetWindowPos oder so.

Zum zweiten wenn ich das Form schließe führe ich diese Function aus:
Function destroy(hwnd As Long)
UnregisterClass "OMain", GethInstance(hwnd)
End Function

Danach kackt Access immer ab und startet neu.

In meinem Buch Win 32 API Professionel wird CreateWindowsEx leider
nicht behandelt, so weiss ich auch nicht welche Konstanten an 1. und
4. Stelle anwendung finden. Gibts darüber irgenwo eine Doku?

Gruß Andreas

[Jens Schilling]

Hallo, Andreas

Post by Andreas Vogt
Hallo,
ich greife ein altes Problem von mir auf und möchte nach den Infos auf
der AEK einen Splitter per API realisieren.

[Snip]

Post by Andreas Vogt
In meinem Buch Win 32 API Professionel wird CreateWindowsEx leider
nicht behandelt, so weiss ich auch nicht welche Konstanten an 1. und
4. Stelle anwendung finden. Gibts darüber irgenwo eine Doku?

Schau mal hier :

http://allapi.mentalis.org/apilist/CreateWindowEx.shtml

Auf der Startseite kannst Du auch den API-Guide herunterladen...

Gruss
Jens

[Jens Schilling]

Hallo, Jens

Post by Jens Schilling
Hallo, Andreas

Post by Andreas Vogt
ich greife ein altes Problem von mir auf und möchte nach den Infos
auf der AEK einen Splitter per API realisieren.

Vielleicht ist Andreas ja auch Beispielen zu Splittern interessiert...

Zum einen gibt es eines in der KnowHow - die wäre hier zu finden :

http://www.freeaccess.de/knowhow.asp

Ein weiteres Beispiel gäbe es hier :

http://www.mvps.org/access/resources/downloads.htm#S

Gruss
Ingrid

[Andreas Vogt]

Hallo Ingrid ;)
Soweit ich weis ist das Beispiel in der KnowHow DB kein API Beispiel.
Und das Beispiel im zweiten Beispiel-Link arbeitet mit GetWindowRect
und ClientToScreen, was zu keinem optisch ansprechendem Ergebnis
führt.
Denke der Weg über das erzeugte Kind-Fenster ist schon der richtige.
Werde mir mal den Link dazu ansehen.

Gruß Andreas

[Jens Schilling]

Hallo, Andreas

Post by Andreas Vogt
Soweit ich weis ist das Beispiel in der KnowHow DB kein API Beispiel.

Ahh - der Weg ist das Ziel ;-)

Post by Andreas Vogt
Und das Beispiel im zweiten Beispiel-Link arbeitet mit GetWindowRect
und ClientToScreen, was zu keinem optisch ansprechendem Ergebnis
führt.

Hab' ich nicht geprüft - nur den Link aus meiner Sammlung entnommen..

Post by Andreas Vogt
Werde mir mal den Link dazu ansehen.

Nimm Dir dort gleich den API-Guide mit - darin sind recht viele
Code-Beispiele enthalten.

[Andreas Vogt]

Hallo,
ja in gewisser Weise ist mir der Weg schon wichtig - das Ergebnis nehm
ich als Bestätigung dass der Weg richtig war oder nicht.
Hab jetzt ein wenig herumexperimentiert, schaffe es aber nicht das
Kind-Fenster sichtbar zu halten. Es blitzt nur mal kurz auf und ist
dann weg.
Hier mein Code:

Public mWnd As Long

Private Const WS_EX_STATICEDGE = &H20000
Private Const WS_EX_TRANSPARENT = &H20&
Private Const WS_CHILD = &H40000000
Private Const CW_USEDEFAULT = &H80000000
Private Const SW_NORMAL = 1
Private Const CS_HREDRAW = &H2
Private Const CS_OWNDC = &H20
Private Const CS_VREDRAW = &H1
Private Const COLOR_APPWORKSPACE = 12

Type WNDCLASS
style As Long
lpfnWndProc As Long
cbClsExtra As Long
cbWndExtra As Long
hInstance As Long
hIcon As Long
hCursor As Long
hbrBackground As Long
lpszMenuName As String
lpszClassName As String
End Type

Private Declare Function CreateWindowEx Lib "user32" Alias
"CreateWindowExA" (ByVal dwExStyle As Long, _

ByVal lpClassName As String, _

ByVal lpWindowName As String, _

ByVal dwStyle As Long, _

ByVal x As Long, ByVal y As Long, _

ByVal nWidth As Long, ByVal nHeight As Long, _

ByVal hWndParent As Long, ByVal hMenu As Long, _

ByVal hInstance As Long, lpParam As Any) As Long

Private Declare Function ShowWindow Lib "user32" (ByVal hwnd As Long,
_
ByVal nCmdShow As
Long) As Long

Private Declare Function DestroyWindow Lib "user32" (ByVal hwnd As
Long) As Long

Private Declare Function RegisterClass Lib "user32.dll" Alias
"RegisterClassA" (lpWndClass As WNDCLASS) As Long

Private Declare Function UnregisterClass Lib "user32.dll" Alias
"UnregisterClassA" (ByVal lpClassName As Any, _

ByVal hInstance As Long) As Long

Function createWnd(hwnd As Long)
Dim OwnClass As WNDCLASS
Dim ClassAtom As Long

' Klasse beschreiben
With OwnClass
.style = CS_OWNDC Or CS_HREDRAW Or CS_VREDRAW
.lpfnWndProc = GetFuncAddress(AddressOf WindowProc)
.hInstance = GethInstance
.lpszClassName = "STATIC"
.hbrBackground = COLOR_APPWORKSPACE
End With

' Neue Klasse registrieren
ClassAtom = RegisterClass(OwnClass)

'Create a new window
mWnd = CreateWindowEx(0, "STATIC", "Hello World !", WS_CHILD, 100,
0, 300, 500, hwnd, 0, GethInstance, 0)

'Show new window
ShowWindow mWnd, SW_NORMAL

'neue Klasse ent-registrieren
UnregisterClass "Static", GethInstance
End Function

Function closeWnd()
DestroyWindow (mWnd)
End Function

Private Function GetFuncAddress(ByVal Address As Long) As Long
GetFuncAddress = Address
End Function

Gruß Andreas

[unknown]

Hallo Andreas,

Post by Andreas Vogt
Soweit ich weis ist das Beispiel in der KnowHow DB kein API Beispiel.
Und das Beispiel im zweiten Beispiel-Link arbeitet mit GetWindowRect
und ClientToScreen, was zu keinem optisch ansprechendem Ergebnis
führt.
Denke der Weg über das erzeugte Kind-Fenster ist schon der richtige.
Werde mir mal den Link dazu ansehen.

hmm, das habe ich scheinbar falsch rübergebracht.
(M)Ein Splitter wird (üblicherweise) über Invert-Funktionen gezeichnet, im
einfachsten Fall über InvertRect(), i.d.R. über PatBlt() mit einem eigenen
Brush, also so wie im zweiten link von Jens. Daß der Splitter als echtes
Fenster ertellt wird, ist eher die Ausnahme (IIRC z.B. bei .Net, aber da
kommts auf die Performance ja eh nicht mehr an...).

Mit CreateWindowEx markiere ich mir nur immer den Ursprung des
Sektionsfensters, um Scrollzustände, die ich beim Zeichnen des Splitters ja
auch noch berücksichtigen muß, leichter ermitteln zu können. Wenn Du im
Beispiel von mvps mal Scrollbars dazu packst wirst Du sehen, daß das dort
aus eben diesem Grund nicht mehr funktioniert.
Dafür verwende ich eine vorgefertigte Windows-Klasse (z.B. Static) habe
also mit der Registrierung per RegisterClass(Ex) an dieser Stelle gar
nichts mehr zu tun.
Ein weiterer Unterschied ist der Flag DSTINVERT bei PatBlt, ich verwende
PATINVERT, noch ein ganz wesentlicher ist der Gerätekontext in den man
zeichnet. Bei mvps wird zudem auf den Screen ausgegeben, das hat den
unangenehmen Effekt, daß ein Splitter beim Bewegen z.b. auch über
Topmost-Fenster gezeichnet wird, passender ist der Gerätekontext des
Sektionsfensters (des ganzes Fenster, nicht der des Clientbereichs).

Wenn Du Dich noch etwas gedulden kannst, gibts die Demo nach dem B-Termin
wie gesagt zum Download und zur freien Verwendung bei Karl.

BTW:
- Mit Deiner CreateWindowEx-Funktion erzeugst Du ein Kindfenster direkt auf
dem Formular. Der einzig sichtbare Teil im Clientbereich desselben ist
aber, wie Du festgestellt hast, der Datensatzmarkierer. Der andere Teil
wird im wesentlichen durch die drei Sektionsfenster eingenommen. Wenn Du
Dein Fenster in der Z-Order nicht darüber definiertst, kann es halt sein,
daß es durch diese Sektionsfenster verdeckt wird. Da Steuerelemente aber
immer Kindfenster eines Sektionsfensters sind, solltest Du bei
CreateWindowEx auch immer ein Sektionsfenster als Parent angeben, nicht das
Formular.
- "OMain" ist die Klasse für das Apllikationsfenster von Access. Diese
Klasse ist also bereits durch Access selbst registriert worden. Eine
weitere Registrierung im selben Prozess sollte ohne Auswirkung bleiben.
Wenn Du hingegen die Klasse wiederer deregistrierst, krachts natürlich.

[Andreas Vogt]

Hallo Jörg,
ah ja, da war doch was mit dem Brush.
War halt in der Kürze der Zeit nciht möglich alles mitzuschreiben.
Danke für deine Ausführungen, die haben mir schon weitergeholfen.
Auf dein Demo-Beispiel bin ich schon gespannt.

Gruß Andreas

[Sascha Trowitzsch]

Hi Jörg,

Ich bin schon dafür gehauen worden, dass ich nicht zur AEK komme, aber es ist
nunmal so... ;-)
Dein Vortrag hätte mich am meisten interessiert.
Nun hab ich schon jemand interviewt, was du dort vermittelt hast, traue mich
aber dennoch, diese Fragen zu stellen:
- Wieweit hast du Codes wie den zum Splitter schon unter A2007 getestet? Meine
Erfahrung mit A2007 ist, dass viele APIs da nicht mehr funktionieren, auch wenn
man Fensterklassennamen etc. anpasst. Oder den MDI-Bereich: Bisher konnte man
den Background mit Pattern-Brush und SetWindowLong setzen, nun geht das aber
nicht mehr und die einzige Lösung wäre Subclassing - mach ich unter VBA nicht.
Lebans etwa hat derzeit leider keine Lust, sich mit A2007 zu beschäftigen und
deshalb funktionieren da diverse seiner Module nicht.
- Siehst du Seiten wie Allapi als ausreichend aus, um in API-Programmierung
reinzukommen? Ich selbst komme ohne das Win32-Platform-SDK nicht aus - das ist
meine einzige Referenz. Das setzt aber voraus, dass man wenigstens ein klein
wenig C-Code lesen kann. Muss sich ein VBA-Entwickler in puncto API also auch
rudimentär mit C beschäftigen, um wirklich über Copy&Paste hinaus kommen zu
können?

Gruß, Sascha


"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb im

Post by unknown
Hallo Andreas,

Post by Andreas Vogt
Soweit ich weis ist das Beispiel in der KnowHow DB kein API Beispiel.
Und das Beispiel im zweiten Beispiel-Link arbeitet mit GetWindowRect
und ClientToScreen, was zu keinem optisch ansprechendem Ergebnis
führt.
Denke der Weg über das erzeugte Kind-Fenster ist schon der richtige.
Werde mir mal den Link dazu ansehen.

hmm, das habe ich scheinbar falsch rübergebracht.
(M)Ein Splitter wird (üblicherweise) über Invert-Funktionen gezeichnet, im
einfachsten Fall über InvertRect(), i.d.R. über PatBlt() mit einem eigenen
Brush, also so wie im zweiten link von Jens. Daß der Splitter als echtes
Fenster ertellt wird, ist eher die Ausnahme (IIRC z.B. bei .Net, aber da
kommts auf die Performance ja eh nicht mehr an...).
Mit CreateWindowEx markiere ich mir nur immer den Ursprung des
Sektionsfensters, um Scrollzustände, die ich beim Zeichnen des Splitters ja
auch noch berücksichtigen muß, leichter ermitteln zu können. Wenn Du im
Beispiel von mvps mal Scrollbars dazu packst wirst Du sehen, daß das dort
aus eben diesem Grund nicht mehr funktioniert.
Dafür verwende ich eine vorgefertigte Windows-Klasse (z.B. Static) habe
also mit der Registrierung per RegisterClass(Ex) an dieser Stelle gar
nichts mehr zu tun.
Ein weiterer Unterschied ist der Flag DSTINVERT bei PatBlt, ich verwende
PATINVERT, noch ein ganz wesentlicher ist der Gerätekontext in den man
zeichnet. Bei mvps wird zudem auf den Screen ausgegeben, das hat den
unangenehmen Effekt, daß ein Splitter beim Bewegen z.b. auch über
Topmost-Fenster gezeichnet wird, passender ist der Gerätekontext des
Sektionsfensters (des ganzes Fenster, nicht der des Clientbereichs).
Wenn Du Dich noch etwas gedulden kannst, gibts die Demo nach dem B-Termin
wie gesagt zum Download und zur freien Verwendung bei Karl.
- Mit Deiner CreateWindowEx-Funktion erzeugst Du ein Kindfenster direkt auf
dem Formular. Der einzig sichtbare Teil im Clientbereich desselben ist
aber, wie Du festgestellt hast, der Datensatzmarkierer. Der andere Teil
wird im wesentlichen durch die drei Sektionsfenster eingenommen. Wenn Du
Dein Fenster in der Z-Order nicht darüber definiertst, kann es halt sein,
daß es durch diese Sektionsfenster verdeckt wird. Da Steuerelemente aber
immer Kindfenster eines Sektionsfensters sind, solltest Du bei
CreateWindowEx auch immer ein Sektionsfenster als Parent angeben, nicht das
Formular.
- "OMain" ist die Klasse für das Apllikationsfenster von Access. Diese
Klasse ist also bereits durch Access selbst registriert worden. Eine
weitere Registrierung im selben Prozess sollte ohne Auswirkung bleiben.
Wenn Du hingegen die Klasse wiederer deregistrierst, krachts natürlich.
--
Grüßle vom Bodensee
Jörg Ostendorp
Access-FAQ: www.donkarl.com

[unknown]

Hallo Sascha,

Post by Sascha Trowitzsch
- Wieweit hast du Codes wie den zum Splitter schon unter A2007 getestet? Meine
Erfahrung mit A2007 ist, dass viele APIs da nicht mehr funktionieren, auch wenn
man Fensterklassennamen etc. anpasst. Oder den MDI-Bereich: Bisher konnte man
den Background mit Pattern-Brush und SetWindowLong setzen, nun geht das aber
nicht mehr und die einzige Lösung wäre Subclassing - mach ich unter VBA nicht.
Lebans etwa hat derzeit leider keine Lust, sich mit A2007 zu beschäftigen und
deshalb funktionieren da diverse seiner Module nicht.

Also die Apis selbst funktionieren nach wie vor ;-) Acess hat sich halt in
vielen Punkten geändert, so daß man entsprechende Funktionalitäten ggf.
anpassen muß. Das Ändern der MDI-Hintergrundfarbe per SetClassLong an sich
funktioniert durchaus, siehe Rückgabewert. Du kannst nur die Änderung nur
nicht mehr sehen, weil Access im Vordergrund noch mal drüberpinselt. Wenn
Du eine entsprechende Funktionalität willst, müßtest Du das Access, wie Du
ja auch schreibst, nun halt per Subclassing abgewöhnen.

Gleiches gilt im Prinzip für sämtliche Manipulationen der
Nonclient-Bereiche sämzlicher Fenster sowie für alle Fenster außerhalb des
MDI-Clientbereichs (abgesehen von Popup-Reports und -Formularen). Da die
Access-Entwickler nunmal beschlossen haben, sich am Rest der Welt mit
eigenen Skins rächen zu müssen, werden sämtliche Style-Änderungen per
SetwindowLong, SendMessage oder ggf. SetWindowsPos von Access beim
Neuzeichnen sofort geschluckt bzw. überdeckt.

Ansonsten tut's bei mir bis auf ein paar kleinere Anpassungen auch
funktionell eigentlich alles recht klaglos.

Was Subclassing betrifft arbeite ich mit der SSubtmr6.dll von
vbaccelerator. Funktioniert weitgehend sehr gut, und der notwendige Verweis
ist IMHO zu verschmerzen. Letztlich bleibt einem wegen der
Antivirenprogramme, insbesondere Kaspersky, heuer sowieso kaum etwas
anderes übrig. VBA funktioniert hier anscheinend wieder einmal anders als
VB.

Und ehrlich gesagt, habe ich mich jetzt an die fehlenden Crashs jetzt auch
schon ein klein bißchen gewöhnt :-)

Post by Sascha Trowitzsch
- Siehst du Seiten wie Allapi als ausreichend aus, um in API-Programmierung
reinzukommen?

Ich kenne jetzt die Seite nicht richtig. Für mich finde ich es nur
wesentlich, daß ich zumindest ungefähr verstehe, wie etwas funktioniert und
warum ich etwas mache, erst dann kommt bei mir auch die Freude an dem
Ganzen auf, weil ich etwas machen und nicht nur nachmachen kann. Zu dem
Verständnis gehört IMO, daß man halbwegs verinnerlicht, wie eine Anwendung
unter Windows tickt,(Fensterklassen, WinMain, Nachrichtenschleife, Threads,
Unterschied SDI/MDI, Grafikausgaben etc.) und speziell bei Access eben noch
die Fensterarchitektur, abgerundet durch einen groben Überblick über die
gängigsten API-Funktion.
Wenn eine Seite das leistet (leichte Zweifel), ist das zumindest schon mal
mehr als halbe Miete. Um eine offizielle Dokumentation komme ich aber nie
drum herum, insofern muß ich meine Nase auch mal in das MSDN stecken.
Speziell für Access halte ich zudem die Beschäftigung mit einem Spyer für
unerlässlich.

Aber um das pathetische Geschwätz noch mal ins rechte Licht zu rücken:
Leider hab ich auch einen ungefähren Überblick darüber, was ich bezüglich
API alles nicht weiß. Ich würde daher nie behaupten, daß ich das Stadium
des "Reinkommens" schon hinter mir hätte ;-)

Post by Sascha Trowitzsch
Ich selbst komme ohne das Win32-Platform-SDK nicht aus - das ist
meine einzige Referenz. Das setzt aber voraus, dass man wenigstens ein klein
wenig C-Code lesen kann. Muss sich ein VBA-Entwickler in puncto API also auch
rudimentär mit C beschäftigen, um wirklich über Copy&Paste hinaus kommen zu
können?

Ja, würde ich schon so sehen, wobei das ja wirklich nur
Minimalanforderungen mit einem Arbeistaufwand "im Minutenbereich" sind.
Meine C-Kenntnisse sind auch einfach nur erbärmlich, das MSDN bzw. SDK sind
aber numal DIE Informationsquellen schlechthin, folglich muß man da halt
durch. Die Sprache sehe ich für mich aber auch gar nicht so als das Problem
an, sondern vielmehr die unterschiedlichen Ebenen auf denen man da mitunter
arbeitet. Wenn z.B. in der Doku irgendwo auf die Nachrichtenverarbeitung in
der WinMain bezug genommen wird, läßt sich das halt nicht 1:1 auf Access
übertragen. Zudem sind die Funktionsbeschreibungen an sich ja auch nicht
immer selbsterklärend.

[Sascha Trowitzsch]

Hi Jörg,

Danke für deine erschöpfende Anwort.

"Jörg Ostendorp" <"Ostendorp(punkt)mpda(at)ecodatadesign(punkt)de"> schrieb im

Post by unknown
Was Subclassing betrifft arbeite ich mit der SSubtmr6.dll von
vbaccelerator. Funktioniert weitgehend sehr gut, und der notwendige Verweis
ist IMHO zu verschmerzen.
...
Und ehrlich gesagt, habe ich mich jetzt an die fehlenden Crashs jetzt auch
schon ein klein bißchen gewöhnt :-)

Ja, nicht, dass ich Subclassing nicht auch einsetzen würde. Aber eben nicht
direkt unter VBA, sondern immer über DLLs, in die ich die Funktionalität
auslagere. Den Subtimer-Code von Mahon nehme ich in leicht modifizierter Form
dann auch in die ActiveX-Dlls, soweit ich sie mit VB6 erstelle.
Aber damit ist die Sache leider auch was für Entwickler, die solche Dlls
erstellen können. Der "normale" Access-Entwickler muss nun damit leben, dass mit
A2007 nicht mehr so viele GUI-Gimmicks gehen, wie sie Lebnas auf seinen Seiten
verbreitet. ;-)
Aber du hast Recht: Bei A2007 ist das ja auch nicht mehr nötig, weil alles
bereits bunt genug ist...

Post by unknown
Leider hab ich auch einen ungefähren Überblick darüber, was ich bezüglich
API alles nicht weiß. Ich würde daher nie behaupten, daß ich das Stadium
des "Reinkommens" schon hinter mir hätte ;-)

Ich kann mir auch nicht vorstellen, dass es *irgendjemand* gibt, der mehr als
einen Überblick hat. Ist doch schlicht unmöglich. Ich finde nun immerhin
innerhalb von sagen wir 2 Minuten im SDK das, wonach ich suche. ;-)

Post by unknown

Post by Sascha Trowitzsch
Ich selbst komme ohne das Win32-Platform-SDK nicht aus - das ist
meine einzige Referenz. Das setzt aber voraus, dass man wenigstens ein klein
wenig C-Code lesen kann. Muss sich ein VBA-Entwickler in puncto API also auch
rudimentär mit C beschäftigen, um wirklich über Copy&Paste hinaus kommen zu
können?

Ja, würde ich schon so sehen, wobei das ja wirklich nur
Minimalanforderungen mit einem Arbeistaufwand "im Minutenbereich" sind.

Ich weiß nicht. Es fängt mit den Problemen bei Datentypen an. Wenn man keine
Deklarationen zur Hand hat, dann kommt man um das Verständnis der Typen nicht
herum. Zu CopyMemory habe ich schon mindestens 4 unterschiedliche
VB-Deklarationen gesehen. Und dann die ganzen Pointer...
BTW: Ich arbeite übrigens fast nur mit der WIN32-TLB von Patrice Scribe,
http://www.vbfrance.com/codes/API-STRUCTURE-TYPE-CONSTANTE-GT-SUFFIT-REFERENCE-TLB_6719.aspx
die IMHO weniger Fehler enthält, als die von Bruce McKinney.
Ist zwar wieder ein Verweis mehr, aber erspart enorm viel Deklarationsarbeit.

Post by unknown
Meine C-Kenntnisse sind auch einfach nur erbärmlich, ...

Schön, dass man da nicht allein ist. ;-)
Habe mich heute gerade durch den C-Code der Beispielprojekte der letzten c't zum
Thema Fehlertolerante Suche gequält. Interessante Sache übrigens,die leider so
nur nicht für Access einsetzbar ist, solange man keine DLLs draus macht.

Gruß, Sascha