Jump to content

GUI/Tray Menu with icons and colors


Holger
 Share

Recommended Posts

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...) :lmao:

Link to comment
Share on other sites

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 by tonedeaf
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :lmao:

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

Link to comment
Share on other sites

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. :lmao:

Link to comment
Share on other sites

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. :lmao:

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 by Valik
Link to comment
Share on other sites

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 :lmao:

So long...

Holger

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...