Advantage of using dlls

J

jccorner

Centurion
Joined
Jan 31, 2004
Messages
144
Not to bore you with details, but I am concerned about 2 things with a project I'm presently working on, first my application size is now over 9mb when compiled using over twenty forms, and secondly should I be breaking down forms into dll’s?

I'm looking to see if there is a certain advantage as to breaking down my project into smaller projects and then use them as dlls and is there a certain size I should be concerned with not going beyond in my application?? I have had some problems with the assembly due to the fact I'm using over three thousand textboxes on certain forms. Thank you for any advice anyone has as to tackling such a large project.
 
The main advantage, in my opinion, is modularization. If you have numerous apps using the same functionality, then you should consider moving it to a DLL.

As for having more than "three thousand" textboxes on a single form, that is most likely the result of a bad design.
 
DLLs will all be loaded into memory and must all be distributed. Generally, all you will be doing is not only increasing the number of files to distribute, but actually increasing data size by creating several assemblies instead of one. As mentioned by Mister E, DLLs are generally used when a certain common functionality is required by multiple assemblies.

I also agree that three thousand textboxes on a single form represents some poor design concept. Something really ought to be broken down more or browsed in a different manner.

I would say that the most important thing you can do at this point is review, revise, and optimize your design, though this may be easier said than done.
 
I've got to ask - what size monitors are your running to be able to display 3,000 textboxes? Even at 100 textboxes per tab a tab control would have over 30 tabs and barely fit on a normal sized screen...

As has been said above DLLs are only really useful if you have logic that can be shared between applications and might not help in this case. You may find improvements can be made by identifying code that is duplicated between forms / controls on a form and moving that into reusable classes to reduce the overheads.

I do think the number of controls per form is possibly the biggest contributing factor to the size and complexity here though, what is the need for so many and could some alternate technique not be used to reduce the number?
 
Just thought I'd mention it as nobody else has, dll's are also usefull for extensibility. They allow you to create a dynamic plug-in system, allowing for additions to your main application without a complete re-compile / distribution of the entire system.

This type of segmentation of code is also quite common amongst game devlopments, this is partly due to the use of third party engines, but also because it makes updates simpler. Most modern games only have a main executable size of below 5mb, compared to an installation side of 1gb+. Granted the majority of this is in the form of model/texture/audio data, but there is certainly extra space being taken up by code. I guess this type of system also made it easier for teams to work on a single project (though i'm assuming vs2005 and team code management takes a step towards solving that).

I'm not saying you should be using dll's I'm merely saying that shared code is not the only valid reason for using them.
 
Without going into too much detail it's for statistical reporting and the client is adamant about the form looking exactly how the report would look.

In the first case, we tried to use a tab control and were able to get 350 textboxes on each tab, but when running the program I ran into an assembly issue which wouldn't allow the program to run anymore.

In the second case, we again used tab controls and had to cut and paste each tab until we found the offending controls which happened to be two textboxes that became corrupt. But when running the app the program would flat line due to the immense amount of data being loaded.

Finally, we opted to have each tab's textboxes copied into seperate forms which looks to be running fine now. My concern is that the size of the compiled app is now exceeding 9mb including the forms, pdfs and well over 50 active reports. I was looking to see if I break up the solution by using dlls would there be any advantage.

I wish to thank all for their advice and suggestions. I will request management to allow a screenshot of one of the forms be shown here so that maybe someone will have another suggestion of how I can display the data and allow the user to change each individual statistic. Thanks again.
 
On a side note about the amount of controls on a page. During the Industrial Placement I did as part of my degree I was working with a 3rd party company creating a computerised version of a paper survey. We suggested they split each section or even each question onto a seperate page (as they are using mobile devices which have limited screen space). The company however were adamant they wanted the layout as simliar to the paper version as possible so they could view all the information at once. This meant there was the equivalent information of over 100 'sets' of checkboxes/radioboxes each set containing 4 ot 5 items. This was overwhelming to me, but then if thats what the customer wants thats what they get. (Though it did mean a complete redesign of the system using shallow copies of the original controls in order to cope with that amount on one page).
 
Instead of playing 350 textboxes onto each tab, you might want to consider using a grid-based control (DataGrid maybe? I've never used one. Excel sheets are another option.) on each tab page to cut way down on the number of contols.

Another very useful memory saving technique would be to re-use controls. Instead of loading 350 textboxes or one datagrid/spreadsheet/whatever per tab, load 350 textboxes or one datagrid/spreadsheet/whatever PERIOD (if you are using textboxes you might want to put them all in a panel within the tabpage). Then, when the user selects a different tab, load the relevant data for that tab into the existing controls and move the controls (or the panel containing the controls) to the selected tab. This way you save yourself a great deal of duplication.

Hopefully someone else who works with data more can give you some specific advice about appropriate controls.
 
Back
Top