[WinAPI] Beste methode om taskbar na te bootsen

[Verwijderd]

Ik gebruik al geruime tijd sharpE als shell in windows. Erg fijn geprogrammeerd enzo, maar de taskbar component ( sharpTask ) heeft heel wat bugs. Dus heb ik besloten om mijn eigen versie in elkaar te steken. Erg moeilijk is dit niet, maar ik stelde mij de vraag wat nu de beste manier is om te bepalen wanneer er windows bijkomen.
• Met een timer elke X milliseconden EnumWindows aanroepen.
• Met een Shell Hook (ik ben niet zeker of deze werkt zonder explorer als shell) .
• Met een CBT hook

Hooks zijn vrij systeembelastend, maar een timer is ook maar ranzig vind ik...
Imo is de shellhook de beste oplossing

Wat vinden jullie ervan of kennen jullie betere manieren om een lijst van toplevel windows up-to-date te houden ?

[LordLarry]

Dat niet, maar een window hetzelfde te laten reageren als een taakbalk heet een AppBar. Misschien wist je dat al, maar anders moet je er even naar kijken.

[Verwijderd]

waarschijnlijk moet je gewoon een Shell Hook gebruiken; volgens mij is dit juist bedoeld voor dit soort dingen, en een shell hook is lang niet zo belastend voor het systeem als een messagehook o.i.d.

[Verwijderd]

LordLarry schreef op 27 december 2002 @ 13:39:
Dat niet, maar een window hetzelfde te laten reageren als een taakbalk heet een AppBar. Misschien wist je dat al, maar anders moet je er even naar kijken.

yup dat wist ik, maar het gaat dus echt om de manier van een windowlist op vragen.
Dus tenzij iemand anders een geniale ingeving heeft, zal het een shellhook worden

[muba]

iiiiiiiiiiiiii wat een ranzig ding is dat zeg... me hele systeem loopt vast gelijk na t booten...

[curry684]

ShellHook is ervoor bedoeld, en het is de meest waterdichte methode. Sowieso is de overhead van hooks redelijk negeerbaar, en de shellhooks geven al helemaal weinig notifications. Daarnaast moet je waarschijnlijk alsnog iedere X seconden EnumWindows aanroepen omdat command prompt-windows andere regels volgen als normale windows, en daardoor hoogstwaarschijnlijk geen Shell-hooks aanroepen. Moet je ff uitproberen dus.

Kweet trouwens niet hoeveel ervaring je hebt, maar onthoud wel dat je een global hook moet maken, geen thread-hook, en dus een goed mechanisme moet hebben om info uit een system-wide-DLL naar je client te krijgen. Daar kan ik je anders wel mee helpen hier en daar

[HunterPro]

MUBA schreef op 27 december 2002 @ 22:32:
iiiiiiiiiiiiii wat een ranzig ding is dat zeg... me hele systeem loopt vast gelijk na t booten...

zeg henk, is dat de bedoeling van dit topic? Ik dacht het niet.

[Verwijderd]

curry684 schreef op 27 december 2002 @ 23:03:
Kweet trouwens niet hoeveel ervaring je hebt, maar onthoud wel dat je een global hook moet maken, geen thread-hook, en dus een goed mechanisme moet hebben om info uit een system-wide-DLL naar je client te krijgen. Daar kan ik je anders wel mee helpen hier en daar

Ik had gedacht om dit te regelen door de DLL een message te laten sturen naar de mainwindow van het programma als er iets veranderd moet worden.

Maar voorlopig ben ik nog bezig met de hook te implementeren, als er nog problemen zijn, schop ik dit topic wel even

[curry684]

Verwijderd schreef op 28 december 2002 @ 20:55:
Ik had gedacht om dit te regelen door de DLL een message te laten sturen naar de mainwindow van het programma als er iets veranderd moet worden.

Food for thought: hoe gaat jouw hook-DLL erachter komen wat de handle is van je mainwindow?

Maar voorlopig ben ik nog bezig met de hook te implementeren, als er nog problemen zijn, schop ik dit topic wel even

Maak maar een nieuw topic, tis wel redelijk different spul

[johnwoo]

curry684 schreef op 29 December 2002 @ 00:34:
[...]

Food for thought: hoe gaat jouw hook-DLL erachter komen wat de handle is van je mainwindow?

Uhh... een FindWindow naar z'n eigen window class?
(met wellicht een mutex om z'n app heen zodat er geen 2 vensters van gemaakt worden)

[Verwijderd]

johnwoo schreef op 29 december 2002 @ 03:43:
[...]
Uhh... een FindWindow naar z'n eigen window class?
(met wellicht een mutex om z'n app heen zodat er geen 2 vensters van gemaakt worden)

indeed. En RegisterWindowMessage gebruiken ipv WM_USER zodat SendMessage geen problemen opleverd mocht er een toevallig andere app zijn met dezelfde WindowClass en WindowText....

[Verwijderd]

misschien is het een optie om in je DLL een lijst bij te houden van windows die de notification message willen ontvangen? dus dat elke applicatie een functie heeft om zichzelf toe te voegen aan de lijst, en om zichzelf weer te verwijderen
het voordeel is dan dat je niet gebonden bent aan de WindowClass, en dat je later de DLL zou kunnen hergebruiken voor iets anders zonder de WindowClass string te moeten veranderen en hem weer opnieuw te compileren onder een andere naam