Shoutbox

quote:

---

Originally posted by Eljay
It's also important to note this isn't something which can really be done "on-the-fly". You have to restart messenger for any of the uifiles to be reloaded.

---

I suppose that depends on what you exactly want to change, where and when. IIRC Patchou once said that some stuff could be done on-the-fly, but Plus! simply reloads Messenger out of 'convenience' so to speak; to avoid difficulties and a lot of messy checks and what not as the purpose of skinning is to skin the entire beast, not just one element or only a chat window or something.

quote:

---

Originally posted by Eljay
It really does seem messy to be modifying Messenger like this from a script...

---

Can't be done from a script though (timing issues and indeed the order of things). You need once again an external DLL I think...

quote:

---

Originally posted by Eljay
Would it be easier to create custom buttons using a skin with certain cmdids that you could then process by subclassing the window?

---

If that would be possible with skinning (I dunno, am not a skinner)... then I suppose it would be easier...

interesting stuff though

Hmm well after playing around for a while (I haven't done much scripting/skinning experimentation for ages, damn uni ) I have managed to add a button with a custom cmdid using a skin and using Mnjul's subclassing dll I have managed to output a message to the debug console when this button is pressed. So this seems like it works ok, but it comes with the problem of having to create a skin for it to work (and if the user already has a skin...)

As for creating a menu, there would need to be some way to communicate with the script from within the dll code so that the script knows when the button is pressed. I couldn't figure out a way to do this in my brief experiment using Mnjul's method (maybe this is easier with the old invisible subclass window method).

It's fun to play around with, but I'm too tired atm and should really be revising...

Going a bit of topic with this I guess.... but

Maybe you actually don't need MnJul's method.

In scripts you can use timers. Let's assume these timers are created internally like any other timer in Windows (seems logical). If that is tru, then couldn't you try to find out the id of the timer as it is known by Windows?

1) Allocate a 1 byte datablock in memory (use to check false triggers later on) and set it to 0xFF.
2) Create a timer and set the interval to maximum (one day)
3) Find out the timer id like it is known by Windows (dunno how this would be done in a reliable way though)
4) Pass that timer id (from Windows) and the datablock address to the DLL

5) When the DLL needs to trigger an event, let it change the datablock's value to 0x0 and..
6) ..let it set the timer's interval to like 10ms (after checking if they still exist of course). Or maybe broadcast a WM_TIMER message to the appropiate hWnd. All depends on how Plus! does its timers.

7) When the timer triggers, the script must check the value of the datablock. If it is 0xFF the timer was falsly triggered (you need to have been signed in for one day for that to happen though). If it is 0x0, the timer was triggered by the DLL. => bingo!
8) In either case, reinitialize the timer and set the datablock again to 0xFF.

So, these are a lot of wild assumptions here (steps 3 and 6 are the problem steps). But might be worthwhile or at least interesting to look into it... then again, it can't be that easy, can't it? lol

-------

And if that fails (very very likely), and you still don't want to create a small dedicated subclassed Plus! window to listen to the DLL, you could use ChatWnd.SendMessage (with MnJul's method) I suppose... which would then trigger to appropiate script event.

-------

Then again, to get back "on topic"... If you're going to use an external DLL anyways, wouldn't it already be able to do whatever this "new feature" is suppose to be doing nativly without the need to call back to the script? Thus no need for anything other then initializing the dll, and call it with the appropiate objects and whatever other stuff you might need (even maybe using MnJul's method to pass the needed Plus! and Messenger objects in case you need them).

I obviously need to get some sleep I suppose

quote:

---

Originally posted by CookieRevised

quote:

---

Originally posted by Eljay
It's also important to note this isn't something which can really be done "on-the-fly". You have to restart messenger for any of the uifiles to be reloaded.

---

I suppose that depends on what you exactly want to change, where and when. IIRC Patchou once said that some stuff could be done on-the-fly, but Plus! simply reloads Messenger out of 'convenience' so to speak; to avoid difficulties and a lot of messy checks and what not as the purpose of skinning is to skin the entire beast, not just one element or only a chat window or something.

---

Before UIFILE was phased out internally, It was a simple 1 or 2 byte patch that allowed for skins to be reloaded, however this only worked for images loaded from the UIFILE itself. Icons for example could only be changed the first time. (For those who are unaware, UIFILEs are no longer used by messenger. Plus! converts skin's UIFILEs to the new binary format at load time)

As far as the painting directly on the chat window goes, you would need have a DLL hook the EndPaint function.  The PAINTSTRUCT that is passed to the EndPaint function *should* still have a valid HDC that you could paint with.  The only problem with this is that you would have to figure out where to draw your custom control based on the size of the window.  Handling of click events can be caught by a subclassing the window.

Perhaps it would be cool to see a skin modification interface added to plus. Something that would allow scripts to add UI elements at either program start or if the programmers are up to the challenge, in real time.

Continuing to play around with communicating the other way via some callback objects... not sure if this is dodgy, my code is probably horrible because I've never done anything like this before but it seems to work ok

This example script just creates an object with a function named "testing". The object is then passed to the dll which invokes the testing method with 2 string parameters.

Back to revision for now anyway

quote:

---

Originally posted by Eljay
As for creating a menu, there would need to be some way to communicate with the script from within the dll code so that the script knows when the button is pressed. I couldn't figure out a way to do this in my brief experiment using Mnjul's method (maybe this is easier with the old invisible subclass window method).

---

I'm pretty sure you can use Interop.GetCallbackPtr inside the DLL to get the address of a jscript function (as long as you know the function name and the number of parameters). Then, cast the return value into an appropriate C++ function pointer then you should be able to call the function.

quote:

---

Originally posted by Mnjul
I'm pretty sure you can use Interop.GetCallbackPtr inside the DLL to get the address of a jscript function (as long as you know the function name and the number of parameters). Then, cast the return value into an appropriate C++ function pointer then you should be able to call the function.

---

afaik, unfortunatly not. That address can only be used for synchronous callbacks, not asynchronous calls. So getting an address might be possible, but it might not be valid anymore at any time.

That is, dunno exactly how the rules go when you use it from inside your DLL though (using your method), but I wouldn't be surprised if the same thing applies for that DLL.

quote:

---

Originally posted by Mnjul
I'm pretty sure you can use Interop.GetCallbackPtr inside the DLL to get the address of a jscript function (as long as you know the function name and the number of parameters). Then, cast the return value into an appropriate C++ function pointer then you should be able to call the function.

---

Unfortunatly not. That address can only be used for synchronous callbacks, not async. So getting an address might be possible, but it might not be valid anymore at any time.

That is, dunno exactly how the rules go when you use it from inside your DLL though (using your method), but I wouldn't be surprised if the same thing applies for that DLL.

quote:

---

Originally posted by Eljay
Continuing to play around with communicating the other way via some callback objects... not sure if this is dodgy, my code is probably horrible because I've never done anything like this before but it seems to work ok

This example script just creates an object with a function named "testing". The object is then passed to the dll which invokes the testing method with 2 string parameters.

---

omg... that can't be working... that was waaaaay too easy and too little code



/me pulls up a barrier so Patchou can't come in spoiling the fun by saying there is a catch

quote:

---

Originally posted by CookieRevised
afaik, unfortunatly not. That address can only be used for synchronous callbacks, not asynchronous calls. So getting an address might be possible, but it might not be valid anymore at any time.

That is, dunno exactly how the rules go when you use it from inside your DLL though (using your method), but I wouldn't be surprised if the same thing applies for that DLL.

---

Well, every time you want to call that jscript function, you call Interop.GetCallbackPtr and use it right away. I think that wouldn't cause you problems. Unless I'm missing something huge here

---

Forgot to say, Eljay, would you mind me putting your codes in my tutorial (with your name attributed to)?

quote:

---

Originally posted by CookieRevised
omg... that can't be working... that was waaaaay too easy and too little code

---

Haha, my thoughts exactly. There just has to be something that breaks magically elsewhere

Haha wow. I didn't notice how much discussion this topic had gotten.

Since I have a feeling I won't be going through with this (doesn't stop me from at least trying though) was to create a spellcheck.

One that works properly, with a squggly red line drawn under mis-spelled words and with the corrections displayed in a popup menu.

Edit
For the part about drawing in the window. Does anyone know if the text box where you enter your chat text has it's own DC or if it's shared with the rest of the window. I remember looking into this quickly and finding that it's shared. :/

If it's not shared and it's unique, I could just subclass the window to receive menu clicks, and draw on it using an external DLL and all should be good.