Is there a way to "cut the fat" from Add-In Express units?

Add-in Express™ Support Service
That's what is more important than anything else

Is there a way to "cut the fat" from Add-In Express units?
Or are you (ADX) willing to add that option? 
Fernando Madruga




Posts: 60
 Joined: 2006-01-04

I noticed that in version 2.4, due to the addition of the Word and Excel WinForms stuff (nice work, btw!), My DLL grew another 78 KB or so. What I would like to know is if there is an easy to moderate way of selecting just the outlook or excel related stuff to go into the DLL? Currently I'm creating a simple Excel add-in and a very simple DLL is 750 KB. Later, I'll be resuming my work on the outlook add-in (the main reason I bought ADX) and so would like to know if there is an easy way to remove support for all the other MS-stuff. I know that, in these days of HDs with 100's of GB, a few hundred KBs of DLL is not too much, but I do like my stuff with little fat in it... :)

I have a sugestion for future versions, but I don't know if this would work, nor if you'd be willing to have that much trouble, and that would be to define some symbols on the project file that would control what does get compiled into the main adx file. E.g., I could define a symbol "ADX_NO_OUTLOOK" and then, in your code, whenever there was something that was outlook related (including the "uses outlook" clause) you could have a "{IFNDEF ADX_NO_OUTLOOK}" clause to not include outlook related stuff. (You could do it the "positive" way, but this way, defining symbols for NOT compiling support, would not break compatibility and would allow for all those like me to simply remove support, in the compiled code, for features that I know will not be using in that project...

Just my two cents...

BTW: I know that, since I do have the source code, I can do that myself, but if I go down that road I'll have a lot more trouble repeating the same process whenever you guys come out with a new release, so built in support for that from your software would be great!

Also, don't forget the sugestion for the OSM'like unit files for Delphi, even if they come without source code: that would be a great thing too!

Later,
Fernando Madruga
Posted 13 Jan, 2006 13:11:41 Top
Fernando Madruga




Posts: 60
 Joined: 2006-01-04
Never mind!

I just spent a couple hours doing that (added a ton of new code lines, enclosing a ton of other lines in blocks such as {$IFNDEF ADX_OUTLOOK}...{$ENDIF ADX_OUTLOOK} and in the end, after adding 11 ADX_NO_xxx defines to the project options (all but ADX_NO_EXCEL), I found out that my DLL only drops from 746.496 to 588.288 bytes... That's not as much as I was expecting, and if I UPX those DLLs, it's down to 240.640 instead of 290.304, so that's a very small difference from excluding all the "other" stuff...

This was a nice opportunity to play around with code templates, though, and they DID made enclosing code blocks between the proper IFNDEF/ENDIF clauses as simple as selecting the code block and then clicking on the template name, well, almost, as BDS does mess around a bit with the indentation of the first and last lines, so I've had to backspace a bit... But at least, there were no mistakes this way...

Nice to see that you did take my sugestion of adding a DELPHI_7_UP and similar symbols, even though you've not yet used it in all the possible places...

I would still like to see a delphi unit that does the same thing OSM does... :)

Later,
Fernando Madruga
Posted 13 Jan, 2006 17:15:19 Top