DLL Newbie - Problems seeing functions?

Okay, okay. I admit I have little clue as to what I'm doing, so bear with me. Here's my (warped?) impression of what a DLL can do for me:

I've got a project that has a large number of functions and subs included. When I distribute the .exe, I'll be wanting to periodically update some of those functions and subroutines. Rather than force my users to re-install a new version of my software every few months, I had a dandy idea - let's stick all the functions into one DLL, and all the subs into another DLL!

Then, I'll add a simple button for users to click that will go and download the newest version of the DLL files. Tada! My program will always be up-to-date. (Have I convinced you I'm naive yet?)

So, here I am sticking all my functions and subs into DLLs when it suddenly occurs to me... I've no real idea what I'm doing. Specifically, I seem to have run into issues with my subs being able to interact with my .exe.

For example, I have a textbox on my form. I can create a DLL with a function that I call from my .exe project, and I can change the value in the textbox. Something like:

Code:

---

  MyTextBox = MyActiveXFunction(MyArgument)

---

However, what if I have a subroutine that wants to directly manipulate my textbox? In my DLL, I'd like to be able to do something akin to:

Code:

---

  MyForm.MyTextBox.Text = WhateverMyDLLSaysItIs

---

However, my DLL can't seem to see my .exe project.

Summary (since I seem to be long-winded):

#1) Am I approaching DLLs correctly? I can put anything I'd like to in there. And I assume there won't be any extra overhead or speed issues if I separate some of my functions and subs from the .exe program.

#2) Can I actually update my program periodically in this fashion? If I check the 'binary compatability' box in the DLL project, I believe I can update my program with the newer DLLs.

#3) How do I get my DLLs to alter my .exe components? It works the other way around (ie, my .exe project can use a sub or function in the DLL project)... so I assume I'm doing something simplistically wrong.

Any help would be greatly appreciated. :)

#1 ok
#2 ok

#3 what ??

Quote:

---

However, what if I have a subroutine that wants to directly manipulate my textbox? In my DLL, I'd like to be able to do something akin to:


MyForm.MyTextBox.Text = WhateverMyDLLSaysItIs

---

what do u mean by this ?

Sorry for the confusion.

The bottom line is this: I have an .exe project and a DLL project. My .exe can see the subs/functions in the DLL, and can use them normally, as if they were part of my .exe project like normal.

However, my DLL cannot see my .exe project. In other words, if I want my DLL to change the text in a textbox, I can't seem to just write:

Code:

---

MyTextBox.Text = "Something here."

---

The DLL project doesn't recognize the fact that I've got another project in my project group, I guess.

In order to have my DLL affect the textbox, it must be a function called by my .exe project where the textbox sits.

...Er, is that any better? :)

yes, sorry I'm getting old and slow :)

u could try passing the textbox to the function as an parameter, not sure that would work though ...

the best thing to do is avoid this. I don't think u'r dll should have anything to do with u'r GUI at all. (Thats my view on it anyway)
makes its reuse value better :)

Why do u have to do it in the first place?
explain that and we might figure a better and more correct way to do it :)

Quote:

---

Why do u have to do it in the first place?
explain that and we might figure a better and more correct way to do it :)

---

Heh, good point. Here's the deal:

I've got an app with a DHTML control on it. There are several subs in the .exe that I was hoping to move to a DLL (in order to easily update just those DLL components when new features are added).

However, some of the subs (and some of the functions) write to the DHTML control, changing the text. Furthermore, some of the subs want to use functions that the .exe has (functions that won't be updated, and hence will remain on the .exe project).

The DLL won't be used again by any other application, so I'm not too terribly concerned about code reusability. The only reason I'm using a DLL is to make it easier to update portions of the code, while the bulk of the project remains as it was.

So, it would be terribly useful if my DLL could see my .exe project's controls, or functions/subs included in that project. I don't doubt that this is probably poor programming - if anybody has a more 'correct' approach, feel free to share. :)

Hopefully, this gives a bit better idea as to where I'm headed. Thanks, Peet, for your feedback.

Quote:

---

Originally posted by Kronix


Heh, good point. Here's the deal:

I've got an app with a DHTML control on it. There are several subs in the .exe that I was hoping to move to a DLL (in order to easily update just those DLL components when new features are added).

---

If u by new features mean new subs/functions then u have to update the exe aswell ??

If its only for changing the already used subs/functions then ok, i see the point.

Quote:

---

However, some of the subs (and some of the functions) write to the DHTML control, changing the text. Furthermore, some of the subs want to use functions that the .exe has (functions that won't be updated, and hence will remain on the .exe project).

The DLL won't be used again by any other application, so I'm not too terribly concerned about code reusability. The only reason I'm using a DLL is to make it easier to update portions of the code, while the bulk of the project remains as it was.

So, it would be terribly useful if my DLL could see my .exe project's controls, or functions/subs included in that project. I don't doubt that this is probably poor programming - if anybody has a more 'correct' approach, feel free to share. :)

Hopefully, this gives a bit better idea as to where I'm headed. Thanks, Peet, for your feedback.

---

I think this will get very messy if possible at all... sorry :)

I would move the functions/subs that do not need any of the code in the GUI or do not need to update any of the controls directly.

I do not know if there is any good way that u'r dll's can see u'r exe's interface/subs and functions.

Its not a good answer, but this is what I think :)

well sure you can do that easily. You just have to pass the objects in the Subs/Functions. For instance, if you wanted to update a textbox on your form in your EXE from your DLL you would write a sub like this.

VB Code:

Sub AddNewText(cControl as Object)
'Lots of code
'Lots more code'
cControl="The new text"
End sub
 
This could be used for all sorts of objects that have Caption and text properties.
Then in your EXE you would call it as such
 
Call AddNewText(text1)

On target!

That's exactly what I was looking for - and such a simple solution. Thanks, Arc. And thanks Peet, who thought it might be possible.

how is it comming along Kronix?

I'm a bit curious :)

It's coming along pretty well... although I'm not terribly adept at this class module stuff.

It seems strange to me, but must I always add an entirely new class module if I want to add another sub or function to the DLL, and allow it to be referenced by other modules in my .exe?

In other words, I've got Mod1 and Mod2, each holding different Subs, call them Sub1 and Sub2. If I put Sub1 and Sub2 BOTH inside Mod1, I can't seem to get my .exe to recognize there's a second sub in there - which seems silly.

A smaller question - how does one declare a type in a DLL? I've got a particular set of constants declared in my .exe using a user-defined type. Something like:

Style.General = 0
Style.Special = 1
Style.Whatever = 2
etc.

However, I'd like my DLL to be able to use the same constants. I can't seem to pass it correctly... Blush. Or conversely, I wouldn't mind setting up the constants in the DLL, and then creating an instance in the .exe, but I'm having trouble with that, too (surprise, surprise). :rolleyes:

Paste this code into a Class Module thats in a DLL project.

VB Code:

Private Type MyType
ref1 As Integer
ref2 As Integer
ref3 As Integer
End Type
 
Sub Msgbox1()
Dim Myref As MyType
Myref.ref1 = 23
Myref.ref2 = 45
Myref.ref3 = 34
Msgbox "Sub Msgbox1 Worked and so did MyType " & Myref.ref1 & " " & Myref.ref2 & " " & Myref.ref3
End Sub
Sub Msgbox2()
Msgbox "Sub Msgbox2 Worked"
End Sub
Sub Msgbox3()
Msgbox "Sub Msgbox3 Worked"
End Sub

Add a new project to your DLL project and set it as the startup. Then paste this code into your Form in Project 2.

VB Code:

Dim Myobj As New class1
Private Sub Command1_Click()
Myobj.MsgBox1
End Sub
 
Private Sub Command2_Click()
Myobj.MsgBox2
End Sub
 
Private Sub Command3_Click()
Myobj.MsgBox3
End Sub

Now save the project. Then set a refrence to your DLL in the project refrences menu. Then run the program and click the buttons. You will see that you are accessing 3 different Methods all coming from the same DLL, and one of the Methods is Using a UDT Inside of it.

Least i think thats what you weree talking about:D

Perfect! Arc's post cleared up a lot of misunderstandings I had about Class modules. Thanks much, all of you.

Now, it seems, things work as I expect them to. Isn't it funny how all of my mistakes are due to 'User Error'... :D