Sueffel,
Are the arguments to the constructor of the class or to the Execute method?
Normally when dealing with dynamically loaded types you need to be
consistent on the parameters expected by the constructors. Some do some
don't can lead to problems, in that how does you program know how many
parameters to pass to the constructor?
Also the Execute method should have a fixed set of parameters for the same
reason, however you could define the Execute method to accept a ParamArray
of strings, which would allow a 'varying number of parameters'.
> In every class, I have the one public function, Execute, which always
> returns something.
In which case each of your classes would implement the ICommand interface,
along with the Execute method.
' framework.dll
Public Interface ICommand
Function Execute(ParamArray args() As String) As Object
End Interface
' simple command.dll
' references framework.dll
Public Class SimpleCommand
Implements ICommand
Function Execute(ParamArray args() As String) _
As Object Implements ICommand.Execute
End Function
End Class
' main executable.exe
' references framework.dll only
Public Sub Main()
' Full type name of one command class
Dim typeString As String = "Simple.SimpleCommand, Simple"
' This is the parameter to the contructor of a comment
Dim param As String = "constructor parameters"
Dim t As Type
t = Type.GetType(typeString)
Dim value As Object
value = Activator.CreateInstance(t, New Object() {param})
Dim command As ICommand
command = DirectCast(value, ICommand)
command.Execute(arg1, arg2)
End Sub
> The biggest concern I have is, I'm only developing
> the app, and a template for the command system, other developers will
> actually be developing the commands separately. It's a bit of a delemma.
I
> will look more into Interfaces though, I will not overlook any suggestions
> at this point in time.
That's all the more reason to define an interface, the Interface tells the
other developers that this is what the HAVE to do, if they don't your
program won't deal with them.
Hope this helps
Jay
"Sueffel" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> "Jay B. Harlow [MVP - Outlook]" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> <SNIP>
> Nope, each command is it's own class, along with any support system it
> may need, including variables, structures, etc.
> I have seen what you are discussing about the interfaces, but I
couldn't
> get it to work with a string variable that defines what command to run.
So,
> I would need something that could use this:
>
> Dim InputStr as String
>
> InputStr=TextBox1.Text 'Defines the command name, or in my case, the name
of
> the class
>
> In every class, I have the one public function, Execute, which always
> returns something. I know that every time it will return the same
datatype,
> such as String, but what I'm hoping to achieve is a level of dynamics of
> returning any datatype and being able to account for it without ever
knowing
> what the command may return. I'm thinking of just using an Object
datatype
> and being done with it. In the model I'm working with, I have two
> overloaded functions that contain the CreateInstance method, one for
> arguments, one without. The biggest concern I have is, I'm only
developing
> the app, and a template for the command system, other developers will
> actually be developing the commands seperatly. It's a bit of a delemma.
I
> will look more into Interfaces though, I will not overlook any suggestions
> at this point in time.
>
> Thank you again Jay,
> Sueffel
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.538 / Virus Database: 333 - Release Date: 11/10/2003
>
>
Similar Threads
