[VB.Net] Office 2003 Style Menus

[anog]

Hi there!

I have created my own Office 2003 style menus in Visual Basic.Net 2003. Some of you might have seen my other thread, but now that I have finished my exams I worked on them a little more.

Here is a screenshot

I currently have support for the Olive, Silver and Blue themes.

If you want to try them out, just run this little program where all three themes are shown. It's just a program with three menus that does nothing. It's just for you to check out the menus

You will need .Net Framework 1.1.

Please post your bugs, thoughts and general feedback! It's not yet finished, but almost. When it is, I'll make the component available for free so you can use it in your own projects.

XPMenus_teste.exe

[smurfiness]

Nice menus. Suggestions:

Put a drop shadow around the toplevel menu item ("File, for example"). You can use GDI+ to draw outside of the menu item's bounds to put a shadow there. If you need help with that email me (dannysmurf@snpsoftware.com). I've dealt with this before, and I've got some code you can have if you want it.

Also, I'd change the colour of the highlighted toplevel items. The gradient just doesn't look right.

[Guest Dan C]

Nice job! (Y)

Will it work with VS C#?

Edited July 22, 2004 by Kracal

[anog]

Kracal:

Yes, it will work with C#. You add it to your project just as another component.

dannysmurf:

Yeah, I'll add a background gradient the width of the form (just like office) and that shadow.

I'll try to work it out by my self (most of the fun is in learning new things while coding!) but if I get stuck i'll email you. Thanks!

[futb0l]

Nice - thanks a lot dude - Might be useful :)

[schwarz2]

that's cool - just to let you know, there's a memory leak in the program it seems - if you watch your mem usage as you go over the menus, it keeps increasing with each new menu brought up. Are you destroying the menus?

[Steven]

Good Job.

(This is build into Visual Studio 2005 :yes: )

[futb0l]

Ooo.. VS 2005 has it :)

[anog]

Yeah, I know VS2005 has it.. But I started this before the VS 2005 express beta came along ;)

schwarz2: Thanks for the tip, I hadn't noticed it. How would I destroy the menus? Any tip? :huh:

[nocture]

you cant really say VS2005 has it, but .NET 2.0 > more specific - windows forms library 2.0 has it.... but yea the menus look great :)

[anog]

you cant really say VS2005 has it, but .NET 2.0 > more specific - windows forms library 2.0 has it

That is just a small technicality ;)

[Jerry Grey Member]

Good Job!! :D

[smurfiness]

schwarz2: Thanks for the tip, I hadn't noticed it. How would I destroy the menus? Any tip? :huh:

You don't destroy the menus. .NET is garbage collected. The menus will be freed at an appropriate time by the runtime. There is no memory leak in your app.

Looking through your code in Reflector, I'm seeing that you create several brushes and rectangles inside the OnPaint function.

It's a typical mistake. Every time you "new" something inside a function like that, the runtime creates a new object every time the function is called. That's normally fine. But if you do this in the OnPaint override for an owner-drawn control, it's creating new objects in memory every time the thing is drawn. In other words, every time a menu item is moused over or brought onto the screen, several brushes and rectangles are being created.

Advice: Create all of the brushes/rectangles/points/etc. that you use in the paint handler outside of the function.

[anog]

Actually, i used this code

? ?
    Public Sub CleanMemory()
 ? ? ? ?System.GC.Collect()
 ? ? ? ?System.GC.WaitForPendingFinalizers()
 ? ? ? ?SetProcessWorkingSetSize(Process.GetCurrentProcess().Handle, -1, -1)
 ? ?End Sub

which does garbage collecting but the mem used keeps increasing. So i'd say there is a leek somewhere..

[smurfiness]

which does garbage collecting but the mem used keeps increasing. So i'd say there is a leek somewhere..

First, .NET applications do not leak memory. A memory leak means that the application has allocated memory that, for some reason, cannot be returned to the system when the application terminates. This is always (always) due to sloppy coding. Since the runtime is responsible for all allocations/deallocations in managed code, there is no room for programmer sloppiness, and the only way it's possible for a .NET application to leak memory is if you're P/Invoking a DLL that is leaking, which you are not doing. So, there is no memory leak in your app.

As far as garbage collecting... in other languages, you destruct objects manually, and their memory is returned to the free memory pool. In .NET, the garbage collector handles that function for you. But it's not at your beck and call. When the GC runs, it looks for the easiest way to free enough memory to keep the application running. It does NOT ruthlessly destroy objects in an attempt to free as much as possible. This means that it favours freeing shorter-lived objects. Objects that do not get freed in a collection (because they're in use, generally) get promoted to a higher level of garbage. Since the GC favours freeing shorter-lived objects, if it doesn't need to free something that exists in (say) generation 2, it won't. So if you're constantly running GC.Collect, objects that cannot be freed earlier on and get promoted may never be freed, because the runtime doesn't think your app needs the memory badly enough to start hacking through the later generations.

Scenario:

You paint a menu item. You have a Brush, a Rectangle, a String and a Point that you create to draw it. You run GC.Collect. Since all of those items are in use for the moment (they either are or just were displayed on screen and haven't been disposed of yet), the GC ignores them and promotes them all to generation 1. The menu item is painted again. You create another Brush, Rectangle, String and Point. You run GC.Collect again. All of the gen 0 items that you just created are in use, so the GC ignores them. The app doesn't actually need the extra memory, so it doesn't bother to collect gen 1. The gen 1 objects are promoted to gen 2, and the gen 0 objects are promoted to gen 1. Lather, rinse, repeat.

Bottom line: You're running the GC over and over and over, and never actually freeing anything. This is why your app is eating up more and more memory. But it's not a leak (all of this memory will be returned to the system when your app exits), and you can solve it very easily by not creating the objects over and over again.

[Cody]

what are some good tutorial like this and for .net basics?

[Steven]

what are some good tutorial like this and for .net basics?

http://msdn.microsoft.com/netframework/ :)

[schwarz2]

i apologize dannysmurf for putting it that way. I just phrased it wrong. Just meant that the memory usage was increasing. :blush:

Now it's my turn to figure out how to do owner drawn menus (actually I found some source to guide me on to creating owner drawn menus in vb - I just have no idea how to do it in popup menus ;)

[anog]

I'm writting my own tutorial ;)

Creating ownerdrawn menus for forms or for context menus (popup menus) is no different. The steps are the same.