BBC BASIC for Windows
Programming >> Libraries >> WINLIB - toolbar limits
http://bb4w.conforums.com/index.cgi?board=libraries&action=display&num=1277202052
WINLIB - toolbar limits
Post by Michael Hutton on Jun 22nd, 2010, 10:20am

I notice that WINLIB has the potential to create a memory leak if the user defines more than one toolbar within the application (potentially within multiple windows or MDI child windows). The 'htool% variable will only keep track of the latest toolbar created and leak previously created toolbar handles into the ether.

I suppose the other potential problem is the creating of the Global 'htool% variable which could lead to clashes with a users program.

It would be difficult to change without causing previous programs to become incompatible when they use PROC_removetoolbar, but maybe a change to pass the toolbar handle when removing it would be warranted ? ....PROC_removetoolbar(htool%)

The only real disadvantage is the potential corruption to the heap when defining more than one toolbar and the user CHAINs, CLEARS or RUNs. And it is not a big drama as I can't remember anyone actually using more than one toolbar!

Michael
Re: WINLIB - toolbar limits
Post by admin on Jun 22nd, 2010, 12:08pm

on Jun 22nd, 2010, 10:20am, Michael Hutton wrote:
I notice that WINLIB has the potential to create a memory leak if the user defines more than one toolbar within the application (potentially within multiple windows or MDI child windows)

Certainly you're right that there is no support for having more than one toolbar. If you think it's desirable, I will add a note to that effect to the docs.

But in practice you can't use WINLIB to put toolbars in "multiple windows or MDI child windows" anyway, because there is no way of passing a parent window handle other than @hwnd%. Microsoft states: "Toolbars work well for primary windows, but are usually overwhelming for secondary windows. For secondary windows, use command buttons, menu buttons, and links instead":

http://msdn.microsoft.com/en-us/library/aa511500.aspx

To the extent that the existing library forces you to adhere to this recommendation, it must be a good thing!

Quote:
I suppose the other potential problem is the creating of the Global 'htool% variable which could lead to clashes with a users program.

The only reasonable alternative to using a global variable is to use PRIVATE, and the problems with that (particularly the incompatibility with ON ERROR) mean you're simply trading off one potential problem for another. If I was writing the library now, I'd incorporate an @ symbol in the variable name, because by convention the user should never be creating a variable name containing an @.

Richard.
Re: WINLIB - toolbar limits
Post by Michael Hutton on Jun 23rd, 2010, 12:10pm

on Jun 22nd, 2010, 12:08pm, Richard Russell wrote:
Certainly you're right that there is no support for having more than one toolbar. If you think it's desirable, I will add a note to that effect to the docs.

I am sure it is not really necessary to do so. I only noticed it when I saw that PROC_removetoolbar didn't have a parameter.

Quote:
But in practice you can't use WINLIB to put toolbars in "multiple windows or MDI child windows" anyway, because there is no way of passing a parent window handle other than @hwnd%.

I haven't checked yet, as I have just sat down but isn't there a way of ensuring child window send all their messages "up the chain' to their parent window.. don't answer this I need to look at the documentation to confirm/deny my premis...

Quote:
To the extent that the existing library forces you to adhere to this recommendation, it must be a good thing!

Exactly.


Quote:
The only reasonable alternative to using a global variable is to use PRIVATE, and the problems with that (particularly the incompatibility with ON ERROR) mean you're simply trading off one potential problem for another. If I was writing the library now, I'd incorporate an @ symbol in the variable name, because by convention the user should never be creating a variable name containing an @.

I recognise the problem of 'updating' any standard library may render it incompatible with previous code, which is not ideal. I would vote to keep the present code. I suppose I was making an observation on limitations.
Michael