Hallo, was ich mich schon seit einiger Zeit frage, ist, wie die Entwickler Steuerelemente in die Titelleiste von Windows-Fenster einfügen. Dies ist z.B. beim aktuellen I-Tunes so und bei Thunderbird: https://dl.dropbox.com/u/21421516/titelleiste%20integrate1.png https://dl.dropbox.com/u/21421516/titelleiste%20integrate2.png Ich arbeite mit C und gcc als Compiler. Viele Grüße, Seb
Die sind nicht in der Titelleiste... Stichworte wären, wenn es in der Titelleiste sein soll, Ribbon Quick Access Toolbar und non-client area http://www.codeproject.com/KB/dialog/AeroNonClientAreaButtons.aspx
Arc Net schrieb: > Die sind nicht in der Titelleiste... > Stichworte wären, wenn es in der Titelleiste sein soll, Ribbon Quick > Access Toolbar und non-client area > http://www.codeproject.com/KB/dialog/AeroNonClient... Naja, aber z.B. bei Itunes, sind da die normalen schließen usw. Buttons obwohl es keine Titelleiste von Windows hat... Und wenn du mal bei Thunerbird schaust gehen zumindest die Tabs mit in die Titelleiste rein. Die ist nämlich bei Windows 8 normalerweise dicker... Ich hab mir das mit C angetan und stelle immer häufiger fest, das es kaum noch eine C API Dokumentation gibt. Die neueren Sachen sind alle C# oder C++ und VB.net (Pfui)...
Seb schrieb: > und stelle immer häufiger fest, das es > kaum noch eine C API Dokumentation gibt. Die Win32-API ist nach wie vor mit C nutzbar, und Owner-Draw-Fenster gibt es in Windows auch schon seit Jahrzehnten. Nichts anderes machen alle von Dir erwähnten Anwendungen, einige davon verwenden vielleicht noch Subclassing, um Standard-GUI-Elemente mit eigenem Zeichencode auszustatten, anderer zeichnen die gesamte Oberfläche komplett selber.
Rufus Τ. Firefly schrieb: > Seb schrieb: >> und stelle immer häufiger fest, das es >> kaum noch eine C API Dokumentation gibt. > > Die Win32-API ist nach wie vor mit C nutzbar, und Owner-Draw-Fenster > gibt es in Windows auch schon seit Jahrzehnten. > > Nichts anderes machen alle von Dir erwähnten Anwendungen, einige davon > verwenden vielleicht noch Subclassing, um Standard-GUI-Elemente mit > eigenem Zeichencode auszustatten, anderer zeichnen die gesamte > Oberfläche komplett selber. Das hier ist aber nicht Owner-Draw, und ich weis jetzt gerade nicht mal obs zur Win32-Api gehört: http://www.codeproject.com/KB/dialog/AeroNonClient
Das ist .Net-Code. Was das genau treibt, wissen nur die, die den Quelltext der .Net-Libraries haben. Final wird das natürlich auch wieder zu Win32-API-Aufrufen.
Könnte man auch ein Fenster ohne Capture machen und einfach die Steuerfelder die in einem "normalen" Programm sind zusätzlich zu den eigenen Steuerfeldern einfügen. Hätte den Vorteil dass man nur ein Fenster verwalten muss.
heinz schrieb: > Könnte man auch ein Fenster ohne Capture machen und einfach die > Steuerfelder die in einem "normalen" Programm sind zusätzlich zu den > eigenen Steuerfeldern einfügen. Hätte den Vorteil dass man nur ein > Fenster verwalten muss. Wenns die Titelleiste als APi Funktion und die Buttons auch gibt, dann wäre das cool. Aber da ich kein Revererse-Eng. betreibe und mir dazu ehrlich gesagt auch die Zeit zu fehlt, wird es mir ein Rätsel bleiben. In der Win-32 API Doku habe ich dazu noch nichts gefunden. PS: .net Aufrufe müssen nicht zwangsläufig in der Win32-API Enden!
Rufus Τ. Firefly schrieb: > Das ist .Net-Code. Was das genau treibt, wissen nur die, die den > Quelltext der .Net-Libraries haben. > > Final wird das natürlich auch wieder zu Win32-API-Aufrufen. Woran erkennst du das? Auf den ersten Blick hätte ich jetzt C++ gesagt. Oder sind das Wrapper-Klassen sowas wie DWM etc.? Ich kenne nur die C-API Funktionen, die dann aber auch sowas in der richtung wie DefWindowProc heißen.
> Das ist .Net-Code. Was das genau treibt, wissen nur die, die den > Quelltext der .Net-Libraries haben. Also jeder der lesen kann scnr http://referencesource.microsoft.com/netframework.aspx Wobei der CodeProject-Artikel auf die verwendeten Win32-Funktionen verlinkt... Zum eigentlichen Problem WM_NCHITTEST, WM_NCPAINT usw. dazu DWM und WS_xyz-Kombinationen
Arc Net schrieb: >> Das ist .Net-Code. Was das genau treibt, wissen nur die, die den >> Quelltext der .Net-Libraries haben. > > Also jeder der lesen kann scnr > http://referencesource.microsoft.com/netframework.aspx > > Wobei der CodeProject-Artikel auf die verwendeten Win32-Funktionen > verlinkt... > > Zum eigentlichen Problem > WM_NCHITTEST, WM_NCPAINT usw. dazu DWM und WS_xyz-Kombinationen So ich hab nun versucht das ganze zu benutzen. Intressanterweise ist der Header für DWM da, allerdings findet der Linker (ld) die dwmapi nicht. Also die Bibliotheksdatei und ich habe ehrlcih gesagt keine Ahnung wo ich diese jetzt auftreiben kann, wenn sie anscheinend nicht von den gcc-Entwicklern mitgeliefert wurde. Ich nutze gcc 4.7.0
Seb schrieb: > PS: > .net Aufrufe müssen nicht zwangsläufig in der Win32-API Enden! Und wo sollten sie es dann tun?
Seb schrieb: > So ich hab nun versucht das ganze zu benutzen. Intressanterweise ist der > Header für DWM da, allerdings findet der Linker (ld) die dwmapi nicht. > Also die Bibliotheksdatei und ich habe ehrlcih gesagt keine Ahnung wo > ich diese jetzt auftreiben kann, wenn sie anscheinend nicht von den > gcc-Entwicklern mitgeliefert wurde. Die dürften im Windows SDK sein http://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx Wenn es nicht zu viele Funktionen sind -> LoadLibrary, GetProcAddress
Rufus Τ. Firefly schrieb: > Seb schrieb: >> PS: >> .net Aufrufe müssen nicht zwangsläufig in der Win32-API Enden! > > Und wo sollten sie es dann tun? Weis nicht, aber seit Windows 64 Bit nicht mehr zwangsläufig die Win32-Api (die ja nicht ohne Grund so heißt wie sie heißt). Arc Net schrieb: > Seb schrieb: >> So ich hab nun versucht das ganze zu benutzen. Intressanterweise ist der >> Header für DWM da, allerdings findet der Linker (ld) die dwmapi nicht. >> Also die Bibliotheksdatei und ich habe ehrlcih gesagt keine Ahnung wo >> ich diese jetzt auftreiben kann, wenn sie anscheinend nicht von den >> gcc-Entwicklern mitgeliefert wurde. > > Die dürften im Windows SDK sein > http://msdn.microsoft.com/en-us/windows/desktop/hh... > Wenn es nicht zu viele Funktionen sind -> LoadLibrary, GetProcAddress Ja hab die dll jetzt aus dem Windows Verzeichnis gefischt und die statt die statische Lib genommen. Allerdings zeigt das jetzt ein sehr komisches Verhalten: https://dl.dropbox.com/u/21421516/dwmextend.png Betreffende Codezeilen:
1 | ...
|
2 | case WM_CREATE: |
3 | {
|
4 | struct sMARGINS marg = {0,0,20,0}; |
5 | DwmExtendFrameIntoClientArea(hwnd,&marg); |
6 | ...
|
1 | ...
|
2 | default: |
3 | DwmDefWindowProc(hwnd, msg,wParam,lParam,&result); |
4 | return DefWindowProc(hwnd,msg,wParam,lParam); |
5 | }
|
6 | ...
|
Alles in
1 | WndProc |
Sharping schrieb: > Rufus Τ. Firefly schrieb: >> Und wo sollten sie es dann tun? > > Neuerdings: in der Windows Runtime. Die wiederum wie .net auch nur Win32 wrappt...
Lukas K. schrieb: > Sharping schrieb: >> Rufus Τ. Firefly schrieb: >>> Und wo sollten sie es dann tun? >> >> Neuerdings: in der Windows Runtime. > > Die wiederum wie .net auch nur Win32 wrappt... Nein, diesmal nicht ;). Die Windows Runtime ist definitiv eine (Teil-) Ablösung der bisherigen Win32-API, also komplett neu und Nativ in C++ geschrieben für Metro basierte Anwendungen auf Windows 8 (nur dort gibt es bisher die WinRT). Das Rendering läuft auch nicht im GDI sondern mit DirectX. Nur hat MS in WinRT nicht alles neu geschrieben (ca. 1800 neue Klassen gegenüber den 12.000 in .NET). Es gibt also neue WinRT-DLLs, die dann nicht mehr sich der bekannten Funktionen aus der alten Win32-API bedienen müssen. Nachzulesen ist das alles auf der Webseite vom ".NET Doktor" H. Schwichtenberg.
g. c. schrieb: > Nein, diesmal nicht ;). Die Windows Runtime ist definitiv eine (Teil-) > Ablösung der bisherigen Win32-API, Hier widersprechen sich deutsche und englische wikipedia: >Examination of the runtime libraries reveals that they are built upon >Win32 API Die deutsche Wikipedia sagt, dass Windows RT auf dem Win32-Subsystem aufbaut, aber gleichberechtigt mit der Win32-API ist.
g. c. schrieb: > Nein, diesmal nicht ;). Die Windows Runtime ist definitiv eine (Teil-) > Ablösung der bisherigen Win32-API, also komplett neu und Nativ in C++ > geschrieben für Metro basierte Anwendungen auf Windows 8 (nur dort gibt > es bisher die WinRT). Das Rendering läuft auch nicht im GDI sondern mit > DirectX. Nur hat MS in WinRT nicht alles neu geschrieben (ca. 1800 neue > Klassen gegenüber den 12.000 in .NET). > > Es gibt also neue WinRT-DLLs, die dann nicht mehr sich der bekannten > Funktionen aus der alten Win32-API bedienen müssen. > > Nachzulesen ist das alles auf der Webseite vom ".NET Doktor" H. > Schwichtenberg. Der ... Ahnung hat... WinRT nutzt Win32... "Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32." http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
Arc Net schrieb: >> ... Nachzulesen ist das alles auf der Webseite vom ".NET Doktor" H. >> Schwichtenberg. > > Der ... Ahnung hat... Denke schon bei den Stundensätzen. ;-) http://win-rt.de/produkte/konditionen.aspx?S > WinRT nutzt Win32... > "Next, a C++ Metro application will still load Win32 DLLs such as > kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – > so they are not a replacement but rather a wrapper, an API flavor, on > top of Win32." >http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx Soweit ich das gelesen habe fügt die WinRT auch neue Funktionen hinzu. Also nur "Wrapper" kann demnach wohl nicht sein. http://www.it-visions.de/lserver/artikeldetails.aspx?b=6241
g. c. schrieb: > Denke schon bei den Stundensätzen. ;-) > > http://win-rt.de/produkte/konditionen.aspx?S Das sind relativ normale Stundensätze, ob er die auch verdient ist eine andere Frage... >> WinRT nutzt Win32... >> "Next, a C++ Metro application will still load Win32 DLLs such as >> kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – >> so they are not a replacement but rather a wrapper, an API flavor, on >> top of Win32." >>http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx > > Soweit ich das gelesen habe fügt die WinRT auch neue Funktionen hinzu. > Also nur "Wrapper" kann demnach wohl nicht sein. > > http://www.it-visions.de/lserver/artikeldetails.aspx?b=6241 "Some Windows Runtime APIs are thin wrappers around existing Win32 APIs (XML and the sensor APIs, for example). Some Windows Runtime APIs are completely new (the XAML APIs and the input stack). So it's not true to say that the windows runtime is a wrapper around Win32, but it is true that parts of the windows runtime are layered on top of Win32." http://stackoverflow.com/questions/7475775/winrt-and-build-in-windows-8-apps http://blogs.msdn.com/b/larryosterman/archive/2011/09/16/what-has-larry-been-doing-for-two-years-and-why-has-the-blog-been-dark-for-so-long.aspx Die XAML-APIs sind zwar neugeschrieben worden, waren davor aber schon vorhanden (WPF/Silverlight/Windows Phone)..., inwieweit der Input Stack noch Win32-Funktionen nutzt entzieht sich meiner Kenntnis "Auch das Rendering von XAML ist in der WinRT nun in nativem Code realisiert und hat damit das Potenzial, schneller zu sein als WPF und Silverlight." Typischer Schwichtenberg... Es gab/gibt in WPF und Silverlight div. Rendering Tiers d.h. je nach Hardware bzw. DirectX-Unterstützung der GPU wird ein Teil in Software gerendert oder alles der GPU überlassen http://msdn.microsoft.com/en-us/library/ms742196.aspx
Wie auch immer. Ist mir im Grunde auch alles nicht so wichtig, solange MS nicht auch WinRT den "ernstgemeinten" ;-) Desktop Windows Versionen wie Windows 7 bereitstellt.
Jeder Hype hinterherrennen. Ich weiß nicht. Aber warte es mal ab bis die "Bringer" erst mal dahinterkommen, dass die gesamte Rückseite eines Formulares noch frei und ungenutzt ist...
Könnte mir jemand jetzt evenutell Helfen? Also um mal zum eigentlcihen Thema noch mal zurückzukommen, hat das jemand schon mal gehabt. Das klappt wie gesagt mit dwm bei mir nicht so wie gewollt. Im zitierten Text isn Screenshot. eee Seb schrieb: > > https://dl.dropbox.com/u/21421516/dwmextend.png > > Betreffende Codezeilen: ... > case WM_CREATE: > { > struct sMARGINS marg = {0,0,20,0}; > DwmExtendFrameIntoClientArea(hwnd,&marg); > ... > ... > default: > DwmDefWindowProc(hwnd, msg,wParam,lParam,&result); > return DefWindowProc(hwnd,msg,wParam,lParam); > } > ... > Alles inWndProc
Im Beispiel http://msdn.microsoft.com/en-us/library/windows/desktop/bb688195(v=vs.85).aspx wird u.a. DwmExtendFrameIntoClientArea in WM_ACTIVATE ausgeführt "This ensures that frame extension is handled properly when the window is at its default size and when it is maximized."
Arc Net schrieb: > Im Beispiel > http://msdn.microsoft.com/en-us/library/windows/de... > wird u.a. DwmExtendFrameIntoClientArea in WM_ACTIVATE ausgeführt "This > ensures that frame extension is handled properly when the window is at > its default size and when it is maximized." Muss ich mal ausprobieren. Aber ich glaube das ich es auch so gemacht habe vorher. Ich probiers mal aus und meld mich sonst noch mal. Danke. Gruß Seb
Arc Net schrieb: > Im Beispiel > http://msdn.microsoft.com/en-us/library/windows/de... > wird u.a. DwmExtendFrameIntoClientArea in WM_ACTIVATE ausgeführt "This > ensures that frame extension is handled properly when the window is at > its default size and when it is maximized." Nein, daran lags also nicht. Habs ausprobiert. Immernoch das selbe Ergebnis. Diesmal ausgeführt in WM_ACTIVATE:
1 | case WM_ACTIVATE: |
2 | {
|
3 | margin marg = {0,0,20,0}; |
4 | DwmExtendFrameIntoClientArea(hwnd,&marg); |
5 | break; |
6 | }
|
Seb schrieb: > Arc Net schrieb: >> Im Beispiel >> http://msdn.microsoft.com/en-us/library/windows/de... >> wird u.a. DwmExtendFrameIntoClientArea in WM_ACTIVATE ausgeführt "This >> ensures that frame extension is handled properly when the window is at >> its default size and when it is maximized." > > Nein, daran lags also nicht. Habs ausprobiert. Immernoch das selbe > Ergebnis. Diesmal ausgeführt in WM_ACTIVATE: case WM_ACTIVATE: > { > margin marg = {0,0,20,0}; > DwmExtendFrameIntoClientArea(hwnd,&marg); > break; > } Mh, keiner eine Idee, woran es liegen könnte?
Hallo, das mit dem "intigrieren" wird nicht klappen, du könntest jedoch versuchen das Steuerelement zu "integrieren". Es grüßt Euer Selbsternannter Weltverbesserer
Selbsternannter Weltverbesserer schrieb: > Hallo, > > das mit dem "intigrieren" wird nicht klappen, du könntest jedoch > versuchen das Steuerelement zu "integrieren". > > Es grüßt Euer > Selbsternannter Weltverbesserer Mh, wie meinst du das?
Selbsternannter Weltverbesserer schrieb: > Hallo, > > das mit dem "intigrieren" wird nicht klappen, du könntest jedoch > versuchen das Steuerelement zu "integrieren". > > Es grüßt Euer > Selbsternannter Weltverbesserer Also ich habs jetzt geschafft denn blauen Frame zu erweitern. Der Trick ist, dass man den Anwendungshintergrund Schwarz einfärben muss, sonst funktioniert es nicht. Allerdings hab ich jetzt das Problem, dass er auf dem Frame die Sachen alle ganz komisch Anzeigt. halt Alles was Schwarz ist, wird jetzt zum Frame, so auch die Texte der Buttons. und ich hab keine Ahnung wie ich das für die Buttons deaktivieren soll. Zudem zeigt er die Menüleiste auch nicht unter dem Frame an, sondern mitten drinne, und soweit ich weis kann man die Menüleiste nicht verschieben, aber Thunderbird hat das ja auch irgendwie geschafft. Und selbst damit sind meine Elemente nicht in der Titelleiste. Bei Microsoft sind sie das aber z.B. z.B. die QuickAccess Toolbar.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.