Shoutbox

I think that the title says it all.

I have a Visual Basic ActiveX dll and I want to call a function that is on my script. I would also need to pass some parameters.

I remember seeing a post on which said how to do that, but I can't find it... (I suck at searching anyway)



Thanks

quote:

---

Originally posted by Felu
See Matty's reply to [Resolved] Talking to VB. .

---

That shows how to call a function from the ActiveX DLL.
Thus "Plus! Script" --> "ActiveX DLL"

What Mike wants is the other way around; how to invoke a function from the Plus! script (as far as I undertood).
Thus "ActiveX DLL" --> "Plus! Script"


This is more complicated (that is, it is still relative easy though).
There are roughly two methods:

• Subclass a Plus! Window and let it listen to Windows messages send from the ActiveX DLL.
  This can be done in roughly two ways:
  
  
  1. Easy way out (not that elegant imho): make a hidden Plus! window with a textbox control. The function in the ActiveX DLL writes something to that textbox control. A Plus! event will trigger and you can read out the contents of the textbox. This isn't that reliable though. This is done in one of -dt-'s scripts I believe, but can't remember which one (don't shoot me if not ).
     
     
  2. More advanced way (more elegant and more reliable): Subclass a Plus! window and let it listen to your own custom made Windows messages you send from the ActiveX DLL. This is done in the SendTo script.
  Both ways don't actually require the ActiveX DLL to be a DLL. That is, it can also be done from any other external program, script, tool, etc.
  
  
• Invoke an event from the ActiveX DLL
  This requires the ActiveX DLL to be a real ActiveX DLL.
  From the ActiveX DLL you invoke an events which will trigger the associated event in the Plus! script. This is done in the Xniff Notifier script.

With all these methods you can pass whatever you like from the ActiveX DLL to the Plus! Script.

Thanks, but I see that the script calls a function and then the DLL returns a value.
I want my DLL to call a function that is on my script and not the script call a function that is on my DLL.

Edit: Just read Cookie's post. I think I'm going to use the 1.A option (for a begging at least)
Btw, what do you mean by "a real ActiveX dll" ?

Both ways of method 1 can be done with anything which supports Windows APIs. Your thing doesn't need to be an ActiveX DLL, or even not be a DLL at all. It can be an exe (eg: like with SendTo), or whatever you make it in (eg: if a DOS batch file would support Windows APIs it could be that too). There is no real bound between your thing and the Plus! script.


For the second method your thing _must_ be an ActiveX DLL as it is the ActiveX object which will be linked to the script. There is a bound between your thing and the Plus! script.


For whatever way you choose (but certainly with method 1), you must _always_ take into consideration that multiple Plus! windows can exist (eg: when the user uses polygamy) and that the Plus! windows don't always exist and/or the script isn't running. Also take into consideration that the user can be switched in Messenger. You do not want to send stuff from your thing to the Plus! script of another user who just logged in instead of the previous one.

quote:

---

Originally posted by CookieRevised
Both ways of method 1 can be done with anything which supports Windows APIs. Your thing doesn't need to be an ActiveX DLL, or even not be a DLL at all. It can be an exe (eg: like with SendTo), or whatever you make it in (eg: if a DOS batch file would support Windows APIs it could be that too). There is no real bound between your thing and the Plus! script.

---

Oh, yes, I understood that

quote:

---

Originally posted by CookieRevised
For the second method your thing _must_ be an ActiveX DLL as it is the ActiveX object which will be linked to the script. There is a bound between your thing and the Plus! script.

---

Since I think that I will use an ActiveX dll to do that (just because I don't think I have a reason to use an exe), can you please explain that method?

quote:

---

Originally posted by CookieRevised
For whatever way you choose (but certainly with method 1), you must _always_ take into consideration that multiple Plus! windows can exist (eg: when the user uses polygamy) and that the Plus! windows don't always exist and/or the script isn't running. Also take into consideration that the user can be switched in Messenger. You do not want to send stuff from your thing to the Plus! script of another user who just logged in instead of the previous one.

---

Right, I forgot about that.
Well, I guess that I can solve this problem quite simply by setting the hidden window's title to the user's email (or a random string?) and then send that string to my DLL. My dll then, would use FindWindow and pass the string the script sent to the dll as the window's title to find the handle of the hidden window.
Or maybe, I could just send the hWnd of the hidden window to my DLL, since MsgPlus has a function of getting the hWnd of a script created window.

quote:

---

Originally posted by Mike

quote:

---

Originally posted by CookieRevised
For the second method your thing _must_ be an ActiveX DLL as it is the ActiveX object which will be linked to the script. There is a bound between your thing and the Plus! script.

---

Since I think that I will use an ActiveX dll to do that (just because I don't think I have a reason to use an exe), can you please explain that method?

---

Look how VB6 plugins were made in Plus! 3, they are ActiveX DLLs. It is exactly the same thing you need to do; create a public class.

The class name you create is the class name you will be using in the Plus! script, for the special syntax and method for that, see the Xniff script.

quote:

---

Originally posted by Mike

quote:

---

Originally posted by CookieRevised
For whatever way you choose (but certainly with method 1), you must _always_ take into consideration that multiple Plus! windows can exist (eg: when the user uses polygamy) and that the Plus! windows don't always exist and/or the script isn't running. Also take into consideration that the user can be switched in Messenger. You do not want to send stuff from your thing to the Plus! script of another user who just logged in instead of the previous one.

---

Right, I forgot about that.
Well, I guess that I can solve this problem quite simply by setting the hidden window's title to the user's email (or a random string?) and then send that string to my DLL. My dll then, would use FindWindow and pass the string the script sent to the dll as the window's title to find the handle of the hidden window.
Or maybe, I could just send the hWnd of the hidden window to my DLL, since MsgPlus has a function of getting the hWnd of a script created window.

---

If you are going to do this using the ActiveX method (method 2), you don't need to test for the correct window as you wont be using any window...

The hidden Plus! window in method 1 is the thing which bounds your thing to the Plus! script. With using ActiveX it is the ActiveX object itself which forms the bound; you don't need a window...

As such, an ActiveX object will be created for each instance of WLM you're running (that is: for each Plus! script which uses the ActiveX DLL), provided you don't change anything in the VB6 ActiveX properties. So this will automatically overcome polygamy problems.


I don't have access to the nessecairy tools atm (VB6 for starters) to give you a complete example in VB6 with associated script though, sorry...



Also, just for the record: Window titles shouldn't be considered unique, or at least a window title should be made as much as possible unique. Setting the title to the email of the user is far from unique! And the Window classes themselfs are certainly not unique either (extremely common mistake to make when people use the FindWindow API). The FindWindow APIs are used way to quickly without knowing their limitations. If you are looking for windows you better always search for windows with the same thread id (thus belonging to the same thread; in this case the thread of the WLM instance) and only in a second phase use the FindWindow API.