GUI/Tray Menu with icons and colors

[Holger]

Hi outthere

here is my script-stuff to create ownerdrawn menuitems with icons and colors.

It uses GUIRegisterMsg() and WM_DRAWITEM / WM_MEASUREITEM - messages proceeding.

Holger

Update 06.05.2008:

!!! Warning: Script breaking !!!

Please change the following commands to:

_TrayCreateItem(Text, ...)

_TrayCreateMenu(Text , ...)

- Fixed: some old values (thanks to aGorilla)

- Fixed: ..SetText() functions (thanks to MrCreatoR)

- Added the following commands:

_SetMenuIconBkGrdColor(Color) ; set icon background gradient color

_SetTrayIconBkGrdColor(Color) ; set icon background gradient color

New sidebar menu commands:

_CreateSideMenu(MenuID) ; returns a SideMenuID/index

_DeleteSideMenu(SideMenuID) ; delete a menu sidebar

_SetSideMenuText(SideMenuID, Text) ; set a text for the sidebar

_SetSideMenuColor(SideMenuID, Color) ; set text color

_SetSideMenuBkColor(SideMenuID, Color) ; set text background color

_SetSideMenuBkGradColor(SideMenuID, Color) ; set text background gradient color

_SetSideMenuImage(SideMenuID, Bitmapfile [, Resourcename/number [, Expand/Compress Bitmap]])

Just take a look into the samples how to use them!

At the moment there are some known issues:

- missing 64bit compatibility (already in progress, to fully work with "AutoIt3_x64.exe")

- moving the mouse cursor on the sidebar menu image/text also changes the current menu item selection

- for sidebar menu image only bitmaps are supported at the moment (min.8bpp)

Update 23.03.2008:

!!! Warning: Please update all your scripts and add after _TrayIconCreate() the command _TrayIconSetState() - otherwise you will not see any tray icons!!!

Also update your icon numbers like for GUI icons

- Fixed: some things (thanks to nickston)

- Changed: _TrayIconCreate() do not show automatically the icon

- Changed: icon behaviour now more similar to GUI icons (I hope)

- Added: command.txt

- Removed: unicode macro

History:

CODE

Update 21.03.2008:

- Changed: dynamic array sizing of the saved menu items

- Added: _TrayDeleteItem(menuID), _GUICtrlODMenuItemDelete($nID) - please delete menu (items) with these commands

- Added: _TrayIconSetState() modes 4 and 8 for flashing and flashstopping of tray icons

- Added: _SetFlashTimeOut([timeOut]) to set the flash timeout

- Added: OnEvent sample

Update 23.02.2008:

- Fixed: GDI object overload while using bold font

Update 22.02.2008:

- Added: _TrayItemSetSelIcon(ItemID, IconFile, IconID) - set the icon if the item is selected

- Added: _GUICtrlODMenuItemSetIcon(ItemID, IconFile, IconID) - set the icon of the item

- Added: _GUICtrlODMenuItemSetSelIcon(ItemID, IconFile, IconID) - set the icon if the item is selected

- Added: "ModernMenuRaw.au3" which only includes the unknown constants, should better work with 'Au3Check' now

Update 12.01.2008-2:

- Fixed: Missing underscore in "CreateMenuFontByName"-function (Font fallback function) (thanks to MsCreatoR and GEOSoft).

- Changed: If a menuitem is disabled then the rect only is showing around the item

- Added: Underscore in menutext only showing when pressing "Alt"-key

Update 12.01.2008:

- Changed: 'local' Dll calls to global DllOpen to speedup (some virusscanners sometimes slowdown the process cause of opening these Dll's again and again)

- Added: Using of @Tab for accelerator showing/drawing

Update 07.12.2007:

- Changed: all stuff in only 1 ZIP file

- Fixed: now works with 3.2.10.0 and 3.2.8.1

Update 03.08.2007

- Fixed: error in _TrayIconDelete() and new creation

- Added: additional parameter to _TrayIconCreate(ToolTip, IconFile, IconID, Callback, Msg, hIcon) to use existing icon handles

- Added: sample_Win2Tray: 'moves' all minimized windows to the tray

Update 28.07.2007

- Fixed: wrong call of function CreateFont() - Thanks to SleepyExtreme for info

- Changed: included samples to demonstrate using of icon clicks

Update 26.07.2007

- Fixed: missing function: LoadIcon()

Update 21.07.2007

- added bold item support - limited to menuitems only, menus are not supported

Update 17.07.2007:

- now you can also menu icons for the tray

- added commands for Tray:

_TrayIconCreate()

_TrayCreateMenu()

_TrayCreateItem()

_TrayItemSetIcon()

_TrayIconSetState()

_TrayTip()

So you can have more than 1 tray icon for 1 Autoit3-script.

Update 01.07.2007:

- now works with unicode (3.2.4.9)

- new command: _GUICtrlODMenuItemSetText(ControlID, NewText)

Update 21.08.2006:

- delete 1 line in libs to work with current release 3.2.0.X (error: cannot redeclare constant...) - Thanks to Javascript_Freek for info

Update 02.02.2006:

- added Checked-state for normal menu items and radio menu items

- added a like ModernMenuLib-script for easier create/use these menustuff (see sample in the ModernMenuLib-folder)

ModernMenuLib_with_Tray.zip

Edited May 6, 2008 by Holger

[tonedeaf]

Gracias!

Is is possible to now have buttons with icons and text?

[Holger]

Take a look into the beta-helpfile "GUIRegisterMsg()" - the example.

I wrote this example to create an ownerdrawn button, so it should not be a problem to build one (also it will take time...)

[tonedeaf]

I've seen that example. Unfortunately I don't understand much of Windows API.

I've noticed that the trend of adding new controls in AutoIt has changed. Earlier the basic controls were made in AutoIt and some extra features were getting added through UDFs. Now the entire control is getting created/manipulated by AutoIt, which is great to show the power of AutoIt but confuses users like me who cannot tackle windows API.

Since you've already worked out the details of owner-drawn Graphical menus, I think it would be easy for you to add it to the core AutoIt engine.

After Status Bars (thanks Gary) and Graphical menus, I've been waiting for AutoIt to support the following controls:

> Buttons with images (BMP, ICO) with text.

> ImageCombo (only supported with latest COMCTL32.DLL)

> Toolbar

No hurry, but would you consider adding support for the these controls to AutoIt? I tried to make a UDF for ImageCombo but couldn't figure out the ImageList control associations which you've already done in your Graphical Menus and Tab (with icons) example.

Thanks again!

EDIT: Spelling

Edited January 30, 2006 by tonedeaf

[Valik]

Since you've already worked out the details of owner-drawn Graphical menus, I think it would be easy for you to add it to the core AutoIt engine.

Owner-drawing does not need to be in the core language. First and foremost is the fact that it requires such a massive library of functions available that it would horrendously bloat the language. The function set for AutoIt would nearly double overnight if all the GDI functions were added (And they would have to be added because they are what makes owner-drawn controls so useful). That brings up the second point. Owner-drawing can't really be simplified very much. Most of the complexity comes from drawing on the control and since drawing on the control is the whole point of owner-drawn controls, where do you simplify? Simplifying how you draw limits what you can draw.

Lastly, GUIRegisterMsg() and thus the support for owner-drawn control has been AutoIt for a week. If the past is any indicator, once this function gains some steam, there will be libraries that appear taking advantage of it. I have no doubt people will start writing examples on how to create all kinds of owner-drawn controls. Once somebody writes a good library, it no longer becomes necessary for something to be built into the language.

[Holger]

Owner-drawing does not need to be in the core language. First and foremost is the fact that it requires such a massive library of functions available that it would horrendously bloat the language. The function set for AutoIt would nearly double overnight if all the GDI functions were added (And they would have to be added because they are what makes owner-drawn controls so useful). That brings up the second point. Owner-drawing can't really be simplified very much. Most of the complexity comes from drawing on the control and since drawing on the control is the whole point of owner-drawn controls, where do you simplify? Simplifying how you draw limits what you can draw.

Lastly, GUIRegisterMsg() and thus the support for owner-drawn control has been AutoIt for a week. If the past is any indicator, once this function gains some steam, there will be libraries that appear taking advantage of it. I have no doubt people will start writing examples on how to create all kinds of owner-drawn controls. Once somebody writes a good library, it no longer becomes necessary for something to be built into the language.

Yeah, I have to agree to Valik, Tonedeaf.

Month ago I wrote internal code to support menu icons but one thing that we all wish I think is a small size of the basic Autoit3.exe.

Cause you don't need all of this additional controls.

The question is how often do you use color'ed menus

I'm using it for my own BartPE taskbar and menu.

However, I also wrote an example for Toolbars and Rebars (a beginning).

And like Valik said, there will comes the time that somebody will write some UDF's to create such additional controls...

Don't really know what you mean with ImageCombo...

But I know in Windows95 you already have a combo with icons in it - it is the tree-combo in the Windows-Explorer which is a ComboEx-control.

So long...

Holger

[tonedeaf]

The function set for AutoIt would nearly double overnight if all the GDI functions were added (And they would have to be added because they are what makes owner-drawn controls so useful).

My focus ins only adding support for graphical menus, so only those GDI funtions which are used in this context need to be added.

For eg. Assuming that it would take approximately the same lines of code in C++ which Holger has demonstrated in this script (if not less). The payload for adding the extra functions in core AutoIt to support owner drawn menus would be around 12 KB (A blank AutoIt script is 172 KB in version 3.1.1.103, Holdger's example compiles to 184 KB)

That brings up the second point. Owner-drawing can't really be simplified very much. Most of the complexity comes from drawing on the control and since drawing on the control is the whole point of owner-drawn controls, where do you simplify? Simplifying how you draw limits what you can draw.

I'm looking for simplification of graphical menus creation, not owner drawing controls in general. I expect the functions to be as simple as creation of list view items. For eg. if the graphical menus owner drawing routines are built in the language, the syntax for creating graphical menus could be as simple as:

$filemenu = GUICtrlCreateMenu ("&File")
$fileitem = GUICtrlCreateMenuitem ("Open",$filemenu)

GuiCtrlSetImage($fileitem, "shell32.dll", 4)

where a single line of GuiCtrlSetImage would wrap all the complexity of owner drawing functions, GuiRegisterMsg etc.

So, given the choice between 12KB overhead vs. simplyfied graphical menus syntax, I would choose the easier syntax, but other users may feel differently.

[Scopinho]

FINALLY!!!!!!!!!!!!

[rambo3889]

This is REALLY NICE

[Faustvii]

This is really nice can i use some of the code to learn this?

Tyvm for this

[Scopinho]

I'm already using it!!!!!!

Thanx again Holger!!!!!

[Valik]

My focus ins only adding support for graphical menus, so only those GDI funtions which are used in this context need to be added.

For eg. Assuming that it would take approximately the same lines of code in C++ which Holger has demonstrated in this script (if not less). The payload for adding the extra functions in core AutoIt to support owner drawn menus would be around 12 KB (A blank AutoIt script is 172 KB in version 3.1.1.103, Holdger's example compiles to 184 KB)

I'm looking for simplification of graphical menus creation, not owner drawing controls in general. I expect the functions to be as simple as creation of list view items. For eg. if the graphical menus owner drawing routines are built in the language, the syntax for creating graphical menus could be as simple as:

$filemenu = GUICtrlCreateMenu ("&File")
$fileitem = GUICtrlCreateMenuitem ("Open",$filemenu)

GuiCtrlSetImage($fileitem, "shell32.dll", 4)

where a single line of GuiCtrlSetImage would wrap all the complexity of owner drawing functions, GuiRegisterMsg etc.

So, given the choice between 12KB overhead vs. simplyfied graphical menus syntax, I would choose the easier syntax, but other users may feel differently.

Damn straight others feel differently and fortunately enough they are the people in charge. What if everybody wanted their "measly 12kb feature" added? AutoIt would be about 5 MB by now (or more). And 12KB is not measely. I can write applications that do quite a lot with less size than that. And to make it even better, not even a dedicated set of functions would simplify it very much so this would just be a complete waste of space. Lastly, in general, writing code in C++ takes more code, not less, so some of the complexity is already hidden from you.

Your expectations, example and preference are all grossly unrealistic. What you want is a narrow-minded feature that is worthless to all but one user of AutoIt (yourself). The fact that the ability to create owner-drawn controls should make you happy, it should not trigger obsurd requests to build in user-specific functionality for simplifying owner-drawing.

If you want owner-drawn menu's, put up or shut up. Either write the code yourself (Any Windows programming book will show you how to use GDI) or shut up and wait until somebody releases a library for easier working with owner-drawn controls.

What's important is that AutoIt can do things, not that AutoIt itself does do things. Remember that in the future the next time you ask for something. You'll have a lot better chance getting user-defined functions to do it if AutoIt is already capable of doing it.

[Holger]

Update: added 2nd script with a more modern like menu.

See first post...

So long

Holger

[YoseMite]

Thanks,

I was looking for a modern menu:)

Looks like XP style...(H)

[RAMzor]

This is very very very cool!

Thanks a lot!

[Josbe]

Update: added 2nd script with a more modern like menu.

See first post...

So long

Holger

Hey, Holger...Thanks for the examples and, of course, the 'Includes' files.

[tonedeaf]

Damn straight others feel differently and fortunately enough they are the people in charge. What if everybody wanted their "measly 12kb feature" added? AutoIt would be about 5 MB by now (or more). And 12KB is not measely. I can write applications that do quite a lot with less size than that. And to make it even better, not even a dedicated set of functions would simplify it very much so this would just be a complete waste of space. Lastly, in general, writing code in C++ takes more code, not less, so some of the complexity is already hidden from you.

Your expectations, example and preference are all grossly unrealistic. What you want is a narrow-minded feature that is worthless to all but one user of AutoIt (yourself). The fact that the ability to create owner-drawn controls should make you happy, it should not trigger obsurd requests to build in user-specific functionality for simplifying owner-drawing.

If you want owner-drawn menu's, put up or shut up. Either write the code yourself (Any Windows programming book will show you how to use GDI) or shut up and wait until somebody releases a library for easier working with owner-drawn controls.

What's important is that AutoIt can do things, not that AutoIt itself does do things. Remember that in the future the next time you ask for something. You'll have a lot better chance getting user-defined functions to do it if AutoIt is already capable of doing it.

What are you talking about? A blank, zero line AutoIt Script compiles to 172 KB. Or are you talking about C++? or Assembly language? In that case 12 KB actually means a lot.

Suddenly, it dawns that almost all of AutoIt GUI functions are redundant after DllStructCreate() got introduced. So, lets take out all these stupid kilobyte consuming functions and learn to use the Windows API CreateWindowEx() functions, because if you don't have Window API level knowledge you'd be asked to put up or shut up.

I've not familiar with the design goals, but what I clearly understand is that AutoIt was developed for easily-understood-scripting.

On merely pointing out the fact that some desired functionality is becoming complex to implement and is assuming low-level C++ knowledge, I'm getting informed by the self-appointed code defender, person-in-charge, solo spokesperson of the developers group who didn't even introduce the said functionality in question that my request is narrow minded and unrealistic.

Probably it is, maybe I should know C++ before I can comment on the functionality of AutoIt. In that case what I'm doing here? helping out on the forum with the tasks which people want to get done. No sir, go and learn how AutoIt is made and until you understand all the implications of your request, don't post or Mr. know-it-all C++ guru is going to come chasing.

Thank you Valik for your extremely helpful solution for the request which I didn't put to you in the first place. That really shows the extra mile you're willing to go to encourage people to use AutoIt.

Cheers!

[Valik]

What are you talking about? A blank, zero line AutoIt Script compiles to 172 KB. Or are you talking about C++? or Assembly language? In that case 12 KB actually means a lot.

I was referring to 12 KB of (compiled) C++ code.

Suddenly, it dawns that almost all of AutoIt GUI functions are redundant after DllStructCreate() got introduced.

Right you are.

So, lets take out all these stupid kilobyte consuming functions and learn to use the Windows API CreateWindowEx() functions, because if you don't have Window API level knowledge you'd be asked to put up or shut up.

What annoyed me most about your idea is it's really coming off as you wanting something for nothing. You really said the wrong things with your narrow focus of only wanting functionality to suit yourself. Most people who want to do something will try to learn to do it.

I've not familiar with the design goals, but what I clearly understand is that AutoIt was developed for easily-understood-scripting.

And it's my personal agenda that AutoIt doesn't require an idiot to use it, either. I constantly harp on the other developer's not to over-simplify things so that advanced functionality can't be achieved. Until Holger's little creation here, I was very hard on JP for over-simplifying the GUI design. Quite literally, I would of rather programmed a GUI in C++ and wrote 200% more code than use AutoIt simply because AutoIt couldn't do the things I wanted. So there is a middle ground that has to be struck in the debate between "simple" and "advanced".

On merely pointing out the fact that some desired functionality is becoming complex to implement and is assuming low-level C++ knowledge, I'm getting informed by the self-appointed code defender, person-in-charge, solo spokesperson of the developers group who didn't even introduce the said functionality in question that my request is narrow minded and unrealistic.

I've never claimed to be the "code defender" or "person-in-charge" nor the "solo spokesperson". It's people like you who go off on insolent rants that give me these titles.

Oh, and by the way. I had a hand in Holger's idea. Holger was stuck and couldn't finish the idea until I came up with a solution and adapted it to suit both Holger and my own needs. So yeah, I kind of did introduce the functionality since the magic that makes it call user functions is my code. I'm not trying to diminish Holger's efforts, most of the code is his and he is the one who put all the work into testing it and documenting it. However, don't assume that because only one developer is listed for a feature that they are the only one who contributed code that makes it work.

Probably it is, maybe I should know C++ before I can comment on the functionality of AutoIt. In that case what I'm doing here? helping out on the forum with the tasks which people want to get done. No sir, go and learn how AutoIt is made and until you understand all the implications of your request, don't post or Mr. know-it-all C++ guru is going to come chasing.

Another title which I have not given myself.

Would you like it if I told you to draw me a picture of my house but I limited you to only using circles? Unless I'm a Hobbit or a baby chicken, chances are, you're not going to be able to do what I ask with any semblance of accuracy. Your request follows a similar path of unreasonable and unrealistic thinking. Okay, so pretend we implement all your ideas for how to draw menu's with a very simple API. What if I don't like the way the menu's look when they are drawn this way? Will you consent to having my similar but different API included? What about when the next person comes along, and the person after that, and the person after that? And we're just talking menu's here. There are over a dozen controls in AutoIt and most of them support owner-drawing. Do you see where I'm going with this? Does this make sense to be in the core language?

Thank you Valik for your extremely helpful solution for the request which I didn't put to you in the first place.

When you make any feature request, you make it to anybody who has access to the source, especially those of us with updated copies of the source.

That really shows the extra mile you're willing to go to encourage people to use AutoIt.

Cheers!

Should I be encouraging people to use AutoIt? Shouldn't the strengths of the language be encouragement enough?

Edit: Forgot a paragraph so I added that.

Edited February 1, 2006 by Valik

[layer]

Looks really nice, Holger. I like it a lot, thanks for your contributions !

[Holger]

Update 02.02.2006:

- added Checked-state for normal menu items and radio menu items

- added a like ModernMenuLib-script for easier create/use these menustuff (see sample in the ModernMenuLib-folder)

See first post

@Valik: thanks for this bigger explaination

So long...

Holger