Considerations on organizing an application... 1

[Fursten]

Hi,

I´m thinking on making a visual basic application that will have an standard exe (the main one ) an other modules (with forms, modules,etc) that I will want to compile in dlls( ActiveX dll)

So the main application will call those dll, that are in fact sub applications(however they have forms too!)

The desavantage that I see in this approch is that I will not be able to run this sub applications...right? However, I will be able to debug them withou any problem...

The other option would be to make all the modules as .exe.
This way they would be consider as diferent application, and I could call them with something like the shell command, right? Is it diferent if I use ActiveX.exe?

I would like to know your opinion...

thank you

 

[SLAbel]

Not sure exactly what you mean..

>>So the main application will call those dll, that are
>>in fact sub applications(however they have forms too!)
>>The desavantage that I see in this approch is that I
>>will not be able to run this sub applications...right?

You should be able to run them...not directly you would need an EXE, your main form would need to create an instance of the class. Somewhere in the class you would need a method that would show the form: FSubForm.Show, you may need to show it modally. You must check the options to be sure the UnAttended execution is NOT chacked. It has been a long time since I have done this. I have created an ActiveX DLL with a form that was made viewable in the way I described above, however, that probably isn't the best way to design your application.

>> The other option would be to make all the modules as
>> .exe. This way they would be consider as diferent
>> application, and I could call them with something
>> like the shell command, right?

Do you need to run each as it's own standalone application? If you do then creating them this way is the only solution.

Why dont you just create sub-forms in your main application? An EXE can ahve as many forms as you need.

Hope that helps.
scott

 

[Guest_imported]

Hello,

The importance in using dlls as my sub applications is that, if the customer only want to buy a part of the application we will not install such dll Got it? With dlls the application becomes more flexible to install and to develop... I think

If I have one main exe and a group of ActiveX dll I expect to call (create an instance) of any of those dlls as I click on a menu item.

Problem: I know that, as dll it will not run as a stand alone application, however I don´t need it to do so! I only need to be able to debug such dll, and I think I could do this. So, I only need to run such dll without compile it. I think this is possible right? For instance, I pretend to have just one connection to the database, that will be created in the main exe, so when I create an instance of a dll it will use that connection.

On the other hand, if I want to debug a dll (without compile it) I will put code on it to create that connection (but before compile it, I will coment such code) so I can test my dll... Is this possible?

Now the exe aproch. If I create diferent sub exe, they will run as stand alone applications but that will be boring. For instance, it will be dificult to control the forms of such exe (if I click on the main exe, the form of the sub exe will go behind the main one). I know tjis because I already made an applications like this. I needed to use Always on top API.. It´s hard to do it with a lot of forms (one after other).

So it seems more reasonable code to do it as dlls. My only doubt is that I will be able to debug those dlls as "stand alone applications"(like open the project and debug them...). I know that I wiil not be able to run it after compiled, but I don´t need it.

Got it?

Thank you

 

[scorpio66]

To debug code in DLLs load your main application and then use File->Add Project to add your DLL to the debugging environment. This works for .ocx files as well.

In my current project I do exactly what you are asking: The main application is fairly stupid, but the functionality is provided in DLLs. One thing I do is to scan the current working directory and use TypeLibInfo for each .dll and .ocx file to see what interfaces they support. This allows the application to determine at run-time what functionality is possible.

I use interfaces A LOT in my application. By way of example:

I have an interface called IAccess: all controls which provide logon functionality MUST implement IAccess. IAccess has the following definitions (as well as others)

Public Property Set DBConnection as Connection
for the database connection

Public Function CanUse() as Boolean
returns T/F if this can be used as an authentication method

Public Property Get AccessGUI() as String
returns a string containing the classname of the GUI element for the access method - i.e. it will return "Logon.LogonBox" for a standard logon/password mechanism. This allows you to do the following:

Public Property Set Notifier() as AccessNotifier
which allows notification messsages to be passed back from the control to the app. AccessNotifier is a simple class which just raises events, ie. eLogonSuccessful, eLogonFailed, eError, etc.

Controls.Add Logon.AccessGUI, Name, ParentControl

to display the logon box.

There are more definitions in my interface but they're the most important.

Good luck - it does increase the amount of work involved in building the app but the flexibility and expandability of the app is worth it.

Chaz

 

[SLAbel]

Hello,

Ok, it sounds to me like you have already made up your mind on which way you want to go. So addressing your question on debugging:

You shouldn't have to change anything to debug the DLL. I am assuming that the EXE and the DLLs are going to be written in VB right? If so you can just create a project group and set the EXE as the startup project and make sure the references point to the loaded DLL project(s). Then you have your whole system in the VB IDE and available to the debugger. and can set breakpoints in all of your loaded DLLs.

Hope that helps
scott