Re: Moving MsgBox

Hi Dan,

"DanS" <t.h.i.s.n.t.h.a.t@xxxxxxxxxxxxxxxxxxxxx> wrote in message news:Xns9AB8CC0506B16thisnthatadelphianet@xxxxxxxxxxxxxxxxx

You need to weigh up the cost/benefits of each approach. If you write
your own, you need to provide the same functionality which includes
wrapping of the message text, flexible set of command buttons ensuring
the correct default button and cancel (ESC) button if needed, changing
the look in accordance with the OS, clipboard set text of the message,
and localization. It's not a huge amount of code, but it is
"reinventing the wheel" considering you already have this provided for
you with MsgBox. Of course if you feel that's "little code" then feel
free to post your version .

Although I prefer the idea of writing your own, in this case hooking
the window maybe less code, especially when you start considering the
localization issues. The real benefit of rolling your own is if you
intend to add other functionality, such as toast window, or
automatically close after n seconds, or "don't ask me this again" kind
of functionality: of course then you really don't have much choice
other than to roll your own.

Well, as you said, it's not a huge amount of code.


Well that depends, adding all the localization as is provided by MsgBox can be considerable developer hours even if the code is not huge.

Forgive me for being a purist, but I stay away from making AX controls to
share between projects. 1) I prefer as few external dependencies as
possible, and 2) individual AX controls take up a huge amount of memory
vs. in-code techniques.


Individual AX controls shouldn't take up a lot of extra memory... the only thing that would do that would be the need to provide the interfaces regsitered. I think the real advantage of having the code inside the project is you can tune/adjust it to that particular project's needs. But the trade-off is you then have ot update all different projects if you discover something that needs to be fixed in your base code.


I can take those liberties though, as I've got a day job.

My shell replacement has a 7-8 meg footprint. Complete shell.


As in windows shell instead of booting into explorer ?


On a whim,
I though I'd package the taskswapper portion into an AX control for
freeware distribution. The taskswapper is a fully functional, provides
context menu support, and is self-updateing, no code would need to be
written, drop it on a form, and there's a taskswapper.

I started a new project transferred all of the code over that was
necessary to use it as an OCX, and compiled the AX control.

I then went into my shell project, and completely removed all code
related to controlling the manual version, and dropped the AX control on
the form, and added code to resize the taskswapper control when needed.

The footprint immediately went from 8'ish megs to over 13 megs.



Memory footprint or combined file sizes ?


Along with the taskswapper, I was going to also release a systray OCX.
This would be a control that is a standalone fully functional system
tray, complete with mouse click callbacks and all, not something to place
an icon in the systray. I never even attempted to package the systray,
because of the memory footprint issue.


There's plenty of Systray.ocx's, I think Microsoft even released the code for one. I don't ever recall memory footprint being an issue there.










.