Calling function of Exe project in referenced aticvex project in vb6

[Ahteshamulhaq]

Calling function of Exe project in referenced aticvex project in vb6

I have one AtiveX project in VB6 (Lets call it A )

i have another Exe project in VB6 (Lets call it B )

Project A is referenced in Project B

but now i have a requirement that i want to call function of B inside A

is there a way Can we do it in VB6?

if yes what do i need to search.Already tried searching on Google but not sure i could explain what to search

As i didn't work much on VB6 so i am kind a stuck here what to do

[Zvoni]

IIRC, you can only call Class-Methods from "outside", but i might be wrong. been a long time for me
You can define a Class as "Global" (or some such thing), and from outside it would look like a Function from a regular "bas"-module (as in: You don't have to qualify the function-name)

[Elroy]

Yeah, if it were me, when B called A, I'd just pass a variable that, when returned, told B to call some procedure within itself and then return (i.e., call again with that info) to A.

Sort of like a callback, but basically just using the same portal for the callback and the return.

Only other thing I can think of is to use AddressOf (with some BAS procedure in B that's passed to A) and then use an API call to call that address. I haven't done that but I could probably work it out.

[Zvoni]

Ah, i see where i got confused
You actually want to call a function in the EXE "B" from your DLL "A"
Easiest way: in your DLL "A" raise an Event which you catch in your EXE "B"
Aircode

'In DLL "A" in module MyClass.cls
Public Event MyEvent(ByVal SomeArgument As Long)

Public Sub MyMethod()
'SomeCode doing Black magic
RaiseEvent MyEvent(1000)
End Sub

'In EXE "B" in a Form or Class-Module
Private WithEvents cSomeClass As MyDll.MyClass

Private Sub cSomeClass_MyEvent(ByVal SomeArgument As Long)
'DoSomething --> AND HERE WE ARE
Debug.Print SomeArgument   'Prints 1000
End Sub

EDIT: Now would you look at that:
https://stackoverflow.com/questions/...project-in-vb6

[Niya]

This is actually a lot more tricky than you realize. If I understand this correctly, you have an normal EXE project that references and ActiveX DLL and you want to be able to call a function in the EXE project from the ActiveX DLL. Do I have that correct? Assuming I am. What you are asking may be impossible to achieve without some serious hacks. You have to get the EXE to export this function and this is under the control of the compiler. As far as I know the VB6 compiler does now allow you to export functions from executables. But assuming you can patch the executable somehow to export the function, you can then use something like GetProcAddress to obtain a pointer to the function and you can use something like DispCallFunc to execute it.

All of this is very involved an in my opinion, not worth the enormous effort. Whatever problem you're trying to solve, I'd advise you think about a completely different direction.

[Niya]

Also if I may, my go-to solution when I need communication across binaries like this and function calls are not an option, I use Winsock to communicate. I don't know what problem you're trying to solve but this may be a solution you can use. But I really must stress that it depends on what you are actually trying to do.

I'd also say that generally speaking if you ever reach a point where you need a DLL to call a function in a host process like an executable, then 9 out of 10 times you seriously screwed up your design somewhere. Unless you're writing malicious code, you should never need to do something like this.

[Zvoni]

Niya,
take a look at the StackOverflow-Link in Post #4 ....
.... illuminating... *g*

[Elroy]

you can then use something like GetProcAddress to obtain a pointer to the function and you can use something like DispCallFunc to execute it.

Niya, you don't need the GetProcAddress piece. Just use AddressOf and pass the address into the ActiveX piece. But yes, DispCallFunc is precisely what I was thinking of. So long as it's all one thread (and in 32-bit address space), that should work just fine. Also, Ahteshamulhaq, you'd need to read up on DispCallFunc and make sure your callback procedure has precisely the correct arguments, or you'll crash things.

Also, there are some somewhat easier alternatives to DispCallFunc. I just don't have them on the tip-of-my-tongue, but I'll find them. API calls where setting up the arguments isn't quite so difficult, but also more pre-defined.

[Zvoni]

*Sigh*
and if you look at the StackOverflow-Link i posted in #4 you would have seen, that it's the same User-Name, the same text as in opening Post,
AND THAT HE RECEIVED ANSWERS 6 Days ago

So why did he register today, and reposted the same question?

[Elroy]

CallWindowProc, that's what I was thinking of. Give me a sec and I'll add an example.

[Elroy]

*Sigh*
and if you look at the StackOverflow-Link i posted in #4 you would have seen, that it's the same User-Name, the same text as in opening Post,
AND THAT HE RECEIVED ANSWERS 6 Days ago

So why did he register today, and reposted the same question?

It is a bit disappointing to see that. IDK, since he just joined, I'll give him the benefit of the doubt. Maybe he found us after making that post.

Ahteshamulhaq, in the future, please give one group a chance to solve your problems before getting other groups going. If you do this repeatedly, I suspect we'll all eventually shun you.

[Niya]

*Sigh*
and if you look at the StackOverflow-Link i posted in #4 you would have seen, that it's the same User-Name, the same text as in opening Post,
AND THAT HE RECEIVED ANSWERS 6 Days ago

So why did he register today, and reposted the same question?

Yea, I noticed. However, it's not something I find odd. I actually think asking the same thing in multiple forums is a very good idea. With the information he got there and the info he gets here it should providing him with more than enough to make a decision on how he wants to solve his problem.

[Elroy]

Here's a trivial example of how to use CallWindowProc:

Code for a BAS module:

Option Explicit

Public Declare Function CallWindowProc Lib "user32.dll" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hWnd As Long, ByVal Msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

Public Sub Proc1(ByVal arg1 As Long, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)
    ' This MUST be in a BAS module.  Public/private doesn't matter so long as AddressOf can reach it.
    ' Sub with all numeric arguments.
    MsgBox arg1 & " " & arg2 & " " & arg3 & " " & arg4
End Sub

Quick test code for a Form1:

Option Explicit

Private Sub Form_Load()
    CallWindowProc AddressOf Proc1, 1&, 2&, 3&, 4&
End Sub

Now, this isn't a callback from an ActiveX DLL, but it very well could have been. Just pass the "AddressOf Proc1" into your DLL, and then put that variable into the call to CallWindowProc.

Note that you are limited to four Long arguments though. Otherwise, you're into the complexities of DispCallFunc.

But I can pass the world with just one Long (32-bit app). I'd just use it as a pointer to a UDT that had whatever I wanted in it.

[Niya]

Also also note that according Olaf/the trick etc can't really remember who said it, DispCallFunc is slower by something like a factor or 4 or some such thing. The CallWindowProc method is near native speed though but it is limited by a fixed number of parameters. Unlike DispCallFunc it cannot be used to call functions with an arbitrary number of parameters.

[Elroy]

Here's how to callback with a string:

BAS module:

Option Explicit
Public Declare Function CallWindowProc Lib "user32.dll" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, ByVal msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long

Public Sub Proc3(arg1 As String, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)
    MsgBox arg1 & "    " & arg2 & " " & arg3 & " " & arg4
End Sub

Test in Form1 (but could have been in an ActiveX DLL if the address was passed in):

Option Explicit

Private Sub Form_Load()
    Dim sArg1 As String
    sArg1 = "Hello World!"
    CallWindowProc AddressOf Proc3, VarPtr(sArg1), 2&, 3&, 4&
End Sub

EDIT: Note that you'll also have to carry that API declaration over to your DLL as well. Hopefully that's sort of obvious though. Maybe I'll make an example (with VBG) as an ActiveX DLL.

[dz32]

just pass a class or form object to the dll as object.

the dll can then call any public methods on that com object late bound (no intellisense)

[Elroy]

Here's a VBG with a Project1 and also a ProjectToCallback (to make into a DLL).

I've got to go for a while so I can't talk about it, but you do have to compile the ProjectToCallback and then re-register it in the Project1 for things to work. But I tested and it works perfectly here.

[Eduardo-]

The two simpler ways would be to raise an event as Zvoni suggested or to send a reference to an object where you can call a method as dz32 said.
Both quite straightforward.

Now, I would like to know what the OP actually needs to do.

[Elroy]

to send a reference to an object where you can call a method as dz32 said.

Ahhh, yeah, I didn't read dz's post closely enough. I actually do that in places. It's easy to pass instantiated object variables into an ActiveX DLL, although they'll need to be late-bound, but that's no big deal. And then, you can call whatever methods of that object you like from the DLL.

[Ahteshamulhaq]

first of all thanks @Elroy @Niya @Zvoni
Yes i have Posted that on stackoverflow and one person suggested a solution too , but i tried that and it was giving error , tried to solve it but could not
so i thought why not post it on specific forum where i noticed helped on VB is Great
special thank to @Elroy for the code and it seems to work

Now there are 2 things

One issue is that i have ActiveX EXE and when i change type of your project from DLL to EXE it give me error


on this line

OurDll.Entry AddressOf Proc3

in project 1

Our project is in ActiveX EXE and Project is VBA (access) and function is in .bas

Second which is more critical that i dont want it to invoke from project 1 i want to call it from Callbackproject button click on form
i have updated @Elroy project

In Callbackproject we have FormInsideDLL, on click of button in it i want to call Proc3

[Ahteshamulhaq]

i have also tried to save the address of function to global and on button click use that but it crash the form
update project is also attached , can you please tell me what i am doing wrong
or we cannot use the address like this

[The trick]

Just use an event. Call RaiseEvent and all the subscribers get the callback.

[wqweto]

Just use an event. Call RaiseEvent and all the subscribers get the callback.

My crystal ball says his "Project is VBA (access)" only has a .bas file so he cannot declare anything WithEvents there which explains why every suggestion so far is not working.

cheers,
</wqw>

[Zvoni]

Just use an event. Call RaiseEvent and all the subscribers get the callback.

With the caveat, that you have to use an object-module to declare your subscriber "WithEvents" (maybe instead of a bas-module one of those "global" autoinstantiated classes which in a way behave like a bas-module?)

[Ahteshamulhaq]

Just use an event. Call RaiseEvent and all the subscribers get the callback.

Tried that too but not able to call it on button event click on ActiveX Exe form

[Ahteshamulhaq]

My crystal ball says his "Project is VBA (access)" only has a .bas file so he cannot declare anything WithEvents there which explains why every suggestion so far is not working.

cheers,
</wqw>

But its not even working on standered EXE and activeX exe

[The trick]

My crystal ball says his "Project is VBA (access)" only has a .bas file so he cannot declare anything WithEvents there which explains why every suggestion so far is not working.

cheers,
</wqw>

Why don't he add an object module? There is no simple methods like AddressOf etc. which will do all marshaling things between processes (because he have AxEXE project which is out-of-proc). Events and an Object variable is quite enough.

[wqweto]

But its not even working on standered EXE and activeX exe

Let me try again.

FormInsideDll in ProjectToCallback:

Option Explicit

Private m_oCallback As Class1
Private m_bConfirmed As Boolean

Friend Function ShowModal(oCallback As Class1) As Boolean
    Set m_oCallback = oCallback
    Show vbModal
    Unload Me
    ShowModal = m_bConfirmed
End Function

Private Sub Command1_Click()
    Dim sArg1 As String
    
    sArg1 = "String to pass back to the main program!"
    'Here we want to call the function Proc3 from Project 1 .bas file
    m_oCallback.FireButtonClick sArg1
End Sub

Private Sub Command2_Click()
    m_bConfirmed = True
    Visible = False
End Sub

Private Sub Command3_Click()
    Visible = False
End Sub

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
    If UnloadMode <> vbFormCode Then
        Visible = False
        Cancel = 1
    End If
End Sub

Class1 in ProjectToCallback:

Option Explicit

Event ButtonClick(arg1 As String, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)

Public Function OpenForm() As Boolean
    With New FormInsideDLL
        OpenForm = .ShowModal(Me)
    End With
End Function

Friend Sub FireButtonClick(arg1 As String, Optional ByVal arg2 As Long, Optional ByVal arg3 As Long, Optional ByVal arg4 As Long)
    RaiseEvent ButtonClick(arg1, arg2, arg3, arg4)
End Sub

Form1 in Project1:

Option Explicit

Dim WithEvents abc As ProjectToCallback.Class1

Private Sub Command1_Click()
    Set abc = New ProjectToCallback.Class1
    If abc.OpenForm() Then
        MsgBox "Form confirmed", vbExclamation
    End If
End Sub

Private Sub abc_ButtonClick(arg1 As String, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)
    Proc3 arg1, arg2, arg3, arg4
End Sub

Here is the test project group fixed: DllWithCallback_GlobalTry_fixed.zip

You'll have to switch ProjectToCallback to Ax-EXE, recompile on your machine and fix project references.

There are at least 3 take-aways from code above:
1. Use With New FormInsideDLL ... End With to instantate forms instead of abusing form's global reference named FormInsideDLL (just don't use it)
2. Call custom methods like ShowModal on the form (not directly built-in Show vbModal) to encapsulate logic, input parameters and return success/failure (form dismissed or confirmed).
3. Use Dim WithEvents abc As ProjectToCallback.Class1 to receive notifications from class/form in another project. This works even with Ax-EXEs.

cheers,
</wqw>

[Elroy]

One issue is that i have ActiveX EXE and when i change type of your project from DLL to EXE it give me error

Ahteshamulahaq, I saw this and didn't even finish catching up on the thread, so someone has probably already answered this.

An ActiveX DLL is an "in-process" thing, whereas an ActiveX EXE is an "out of process" thing. The differences that matter to us is that they have their own process thread and also their own address space. So, you're correct, none of this works for an ActiveX EXE.

Personally, I've never found a good use for an ActiveX EXE, and that a fully function program that stands on its own serves just as well (but I'm sure others will have some objections to that statement).

To communicate between two entirely different processes, there are several approaches, but, if we're to do it not using disk space, I always use calls to the SendMessageTimeout API and also do a bit of subclassing on the window I'll use to receive the message.

Here's a CodeBank entry of mine where I do precisely that. Basically, it's a persistent debug window (one that outlives the life of your project in case your project crashes the IDE). It's uni-directional, but there's nothing that stops you from setting up the whole process in reverse so that two processes can communicate with each other.

All of this gives you the added benefit that you're operating with two threads (and two processes), thereby giving you the ability for both processes to be simultaneously processing (or hang awaiting some signal if you so desired).

Also, just to say it, if you insist on an ActiveX EXE, that SendMessageTimeout approach would work just fine.

-------

EDIT: Ok, all caught up now, and nobody suggested my SendMessageTimeout approach, so it's another option for you. But also, let me say that you've got some fine programmers assisting you in this thread, and there should be some solutions that will work for you. If the initiating program is VBA, that is a complicating factor though. However, the SendMessageTimeout approach should still work. Basically, all you need is a hWnd on the receiving side that you can subclass, which you can clearly have with the VBA, or an ActiveX EXE, or a stand-along program.

[Zvoni]

One approach not mentioned up until now is DDE

And that one definitely works with an ActiveX-exe

[Elroy]

One approach not mentioned up until now is DDE

And that one definitely works with an ActiveX-exe

Yeah, I used to use DDE, but it was always so finicky that I finally gave it up for the SendMessageTimeout approach. But yeah, DDE will work across processes. I think I've got some old DDE post somewhere in these forums.

[Ahteshamulhaq]

Let me try again.

FormInsideDll in ProjectToCallback:

Option Explicit

Private m_oCallback As Class1
Private m_bConfirmed As Boolean

Friend Function ShowModal(oCallback As Class1) As Boolean
    Set m_oCallback = oCallback
    Show vbModal
    Unload Me
    ShowModal = m_bConfirmed
End Function

Private Sub Command1_Click()
    Dim sArg1 As String
    
    sArg1 = "String to pass back to the main program!"
    'Here we want to call the function Proc3 from Project 1 .bas file
    m_oCallback.FireButtonClick sArg1
End Sub

Private Sub Command2_Click()
    m_bConfirmed = True
    Visible = False
End Sub

Private Sub Command3_Click()
    Visible = False
End Sub

Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
    If UnloadMode <> vbFormCode Then
        Visible = False
        Cancel = 1
    End If
End Sub

Class1 in ProjectToCallback:

Option Explicit

Event ButtonClick(arg1 As String, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)

Public Function OpenForm() As Boolean
    With New FormInsideDLL
        OpenForm = .ShowModal(Me)
    End With
End Function

Friend Sub FireButtonClick(arg1 As String, Optional ByVal arg2 As Long, Optional ByVal arg3 As Long, Optional ByVal arg4 As Long)
    RaiseEvent ButtonClick(arg1, arg2, arg3, arg4)
End Sub

Form1 in Project1:

Option Explicit

Dim WithEvents abc As ProjectToCallback.Class1

Private Sub Command1_Click()
    Set abc = New ProjectToCallback.Class1
    If abc.OpenForm() Then
        MsgBox "Form confirmed", vbExclamation
    End If
End Sub

Private Sub abc_ButtonClick(arg1 As String, ByVal arg2 As Long, ByVal arg3 As Long, ByVal arg4 As Long)
    Proc3 arg1, arg2, arg3, arg4
End Sub

Here is the test project group fixed: DllWithCallback_GlobalTry_fixed.zip

You'll have to switch ProjectToCallback to Ax-EXE, recompile on your machine and fix project references.

There are at least 3 take-aways from code above:
1. Use With New FormInsideDLL ... End With to instantate forms instead of abusing form's global reference named FormInsideDLL (just don't use it)
2. Call custom methods like ShowModal on the form (not directly built-in Show vbModal) to encapsulate logic, input parameters and return success/failure (form dismissed or confirmed).
3. Use Dim WithEvents abc As ProjectToCallback.Class1 to receive notifications from class/form in another project. This works even with Ax-EXEs.

cheers,
</wqw>

Thanks @wqweto
back from few holidays
and i use your approach and it seems to work
will update you when i completely do it

one issue left that when i open modal with

OpenForm = .ShowModal(Me)

it took so long and i need to click button many time then this popup appear

After clicking "switch to" many time then it open the form
any idea why ?


and how can i open the form without modal (with form.show() ) and pass the "Me" with it

[wqweto]

I didn't realize you needed non-modal interaction here. There are many possibilities but I would "wrap" form's lifetime with abc's lifetime (the instance of ProjectToCallback.Class1).

This way when you release abc you'll get your form unloaded. You can call methods on abc which do "actions" on the form and you can receive events from abc when the end-user interacts with the form.

One thing you must take care of is not making circular references. Storing the Me reference (passed in ShowModal) in a member variable would lead to such problem.

Edit: Here is a full sample: DllWithCallback_GlobalTry_nonmodal.zip

cheers,
</wqw>

[Ahteshamulhaq]

I didn't realize you needed non-modal interaction here. There are many possibilities but I would "wrap" form's lifetime with abc's lifetime (the instance of ProjectToCallback.Class1).

This way when you release abc you'll get your form unloaded. You can call methods on abc which do "actions" on the form and you can receive events from abc when the end-user interacts with the form.

One thing you must take care of is not making circular references. Storing the Me reference (passed in ShowModal) in a member variable would lead to such problem.

cheers,
</wqw>

I can live with Modal approach as well but not sure why its taking time and why this popup keep on coming

and what do you mean by

I would "wrap" form's lifetime with abc's lifetime (the instance of ProjectToCallback.Class1).

[wqweto]

and what do you mean by

I would "wrap" form's lifetime with abc's lifetime (the instance of ProjectToCallback.Class1).

Check out the full sample link above. When you press "Open DLL form" button while there is already a form open it asks you if would like a second instance.

The moment it instantiates a second instance with Set abc = New ProjectToCallback.Class1 it is the first instance which is released and terminated. This *unloads* the first form too.

This is what bound lifetimes look like -- the form lives until (last reference to) abc is released.

You can store each new abc spawned in a collection and allow multiple forms being alive although sinking events from such collection will require more wrappers.

cheers,
</wqw>

[xiaoyao]

CAN USE rot like createobject

[Elroy]

I've dealt with that timeout error quite a bit in the past:



I automate Word and Excel quite a bit from VB6, and you've got to be super-careful to not have either of those come up with any kind of prompt during automation or you'll get that error. I suppose something that takes longer than the internal timeout would also cause it to come up, but I don't think I've ever done that. It's almost (if not always) been when Word or Excel put up some modal message that I didn't suppress (or work around).

Maybe that information will help. When controlling one program from another, you've got to make sure the controlled program is responsive to the controller program, or you'll get that message.

[wqweto]

I've dealt with that timeout error quite a bit in the past:



I automate Word and Excel quite a bit from VB6, and you've got to be super-careful to not have either of those come up with any kind of prompt during automation or you'll get that error. I suppose something that takes longer than the internal timeout would also cause it to come up, but I don't think I've ever done that. It's almost (if not always) been when Word or Excel put up some modal message that I didn't suppress (or work around).

Maybe that information will help. When controlling one program from another, you've got to make sure the controlled program is responsive to the controller program, or you'll get that message.

There a lot of properties on App object which control this message. I usually set some absurd timeout like

App.OleRequestPendingTimeout = 2 ^ 31 - 1

. . . and never see this prompt again. Together with calling this API function

Private Declare Function DisableProcessWindowsGhosting Lib "user32" () As Long

. . . these make my LOB apps "unbreakable" like Bruce Willis :-))

cheers,
</wqw>
p.s. Anyone else been watching Die Hard this Christmas, again?

[jpbro]

Yippee Ki Yay (My Friend)

[Ahteshamulhaq]

Check out the full sample link above. When you press "Open DLL form" button while there is already a form open it asks you if would like a second instance.

The moment it instantiates a second instance with Set abc = New ProjectToCallback.Class1 it is the first instance which is released and terminated. This *unloads* the first form too.

This is what bound lifetimes look like -- the form lives until (last reference to) abc is released.

You can store each new abc spawned in a collection and allow multiple forms being alive although sinking events from such collection will require more wrappers.

cheers,
</wqw>

thanks @wqweto
its seems your solution worked
but i face another issue that one of the parameter in function which we use as event from one project to another is type control

now how can i send control as parameter - i tried that and it give me error


i tried to send form too but it didnt work
can i create control in VBA dynamically
i have posted a question as well for that , or is there any solution