Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Suggestions
➜ New return value for SendXxx family of functions.
New return value for SendXxx family of functions.
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Posted by
| Worstje
Netherlands (899 posts) Bio
|
Date
| Sun 12 Aug 2007 04:26 PM (UTC) Amended on Sun 12 Aug 2007 04:29 PM (UTC) by Worstje
|
Message
| Right now, the SendXxx family of functions have the following possible return values:
eWorldClosed : The world is closed
eItemInUse : Cannot be called from within OnPluginSent script callback
eOK: Sent OK
What I am missing is a way to determine if it was REALLY sent. If an OnPluginSend of ANY plugin happens to reject what I am sending, my tracking could be off. Of course, I could add an elaborate procedure with OnPluginSent, a table (or list in Python) with commands I've been trying to send and a wrapper around it, but it will get clumsy and make what could be a simple if statement into a project of its own.
Suppose you could write the following:
local sentMedicine = world.SendNoEcho("take medicine")
if (sentMedicine == ePluginBlocked) then
-- Apparently this is not a time to take our medicine.
-- Echo it.
World.Note("Warning: you have not taken your hourly medicine!")
end
I believe it should be possible, since the OnPluginSend really does get called from the various Send() functions according to my tests. The only disadvantage is that it might break some scripts, so in that case I suggest only putting it in the more recently added 'SendSpecial' function which might break less existing scripts. | Top |
|
Posted by
| Shaun Biggs
USA (644 posts) Bio
|
Date
| Reply #1 on Sun 12 Aug 2007 06:23 PM (UTC) |
Message
| OnPluginSend already can assign a true or false to be returned. It shouldn't be too hard to make the false send back a different error code than it already does. Just adding a new error code shouldn't interfere with existing scripts if they check for eOK. It would just add other option to check for ePluginBlocked or whatever it would be called.
I haven't poked around with OnPluginSend much. Can you test to see if eOK is not sent back?
local sentMedicine = world.SendNoEcho("take medicine")
if (sentMedicine ~= eOK) then
-- Apparently this is not a time to take our medicine.
-- Echo it.
World.Note("Warning: you have not taken your hourly medicine!")
end
|
It is much easier to fight for one's ideals than to live up to them. | Top |
|
Posted by
| Worstje
Netherlands (899 posts) Bio
|
Date
| Reply #2 on Sun 12 Aug 2007 07:12 PM (UTC) |
Message
| I've done a quick test with a different plugin, and both cases return 0 (=eOK). | Top |
|
Posted by
| Shaun Biggs
USA (644 posts) Bio
|
Date
| Reply #3 on Sun 12 Aug 2007 08:48 PM (UTC) Amended on Sun 12 Aug 2007 08:49 PM (UTC) by Shaun Biggs
|
Message
| As I said, I haven't played around with the function. From the help file, I mistakenly got the impression that an error would be returned:
OnPluginSend
'
' MUSHclient is sending 'sText' to the MUD
' Return TRUE to send the text, FALSE to discard it
'
Function OnPluginSend (sText)
OnPluginSend = vbTrue ' process it
End Function
The issue with trying to see if the send was blocked is that sometimes the send goes through fine, sometimes people will modify the string that is sent, and other times it just sends other strings as well. I agree that there should be some way to tell if the last send was modified in some way, but it could be tricky to figure out the best way to deal with this. |
It is much easier to fight for one's ideals than to live up to them. | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #4 on Sun 12 Aug 2007 09:42 PM (UTC) |
Message
| The problem with that idea is that sends are not synchronous.
When you call 'Send' the text to be sent is queued (after any speedwalks) and pulled out of the queue later on. When it is pulled out of the queue the function OnPluginSend is called.
The callback OnPluginSent was designed for things like the automapper (and other stuff like you are talking about) where you want to keep track of what was actually sent, rather than what was queued.
Here is a possibility of what might happen:
- You are busy speedwalking with 30 seconds to go (30 directions with a 1 second delay between each one)
- You send SendNoEcho("take medicine")
- You get no error
- 15 seconds later you cancel the speedwalk queue
- The "take medicine" is in the queue and gets cancelled as well
Conceivably the test could be added to SendImmediate, which does not suffer from this problem. I see from the source that the call to OnPluginSend is done by the routine directly called by SendImmediate, so with a bit of reworking that could be done.
However the idea of using OnPluginSent is a bit more reliable. Say for example you manually typed "take medicine" - a test in OnPluginSent would catch that. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Worstje
Netherlands (899 posts) Bio
|
Date
| Reply #5 on Sun 12 Aug 2007 10:04 PM (UTC) Amended on Sun 12 Aug 2007 10:09 PM (UTC) by Worstje
|
Message
| Well, I don't care about speedwalks (it is about the only MUSHclient feature I don't use at all), so that's fine with me. The issue with using the OnPluginSen(d|t) callback isn't as useful for a few reasons:
1) You'd need to use a plugin and can not use the function in your worlds triggers.
2) The code to deal with this would be spread out over the place where you call it and the place where you 'reject' it.
2a) With OnPluginSend, you may run into the issue that some function tries to execute another tell (if I haven't taken medicine, tell my doctor that I may get ill some time today). This one will always go through, which might not be acceptable when you are using OnPluginSent to stop certain actions. (Okay, it is a weird example situation and I can't think of a better one right this moment, but I have the feeling it is a restriction which I would rather quickly run into, knowing my insane usage of OnPluginSent). This would only handle blocking of messages by -this- plugin, and not by others.
2b) With OnPluginSent, you could only react to allowed actions.. and not to actions that aren't allowed.
2c) 2a and 2b mean that the only conceivable way of using it would be a timer with a very short interval, which has the disadvantage of needing timers enabled AND being unable to send things in one trigger dependant on the result of another, unless daisy-chaining (which would be a very ugly solution imho.)
3) Every plugin-author would have to re-invent this particular system to be able to use it. Or require a certain basic plugin to be available, which in turn would call an alias or method using CallPlugin().
4) If you only want to know whether a certain text could be sent in a certain situation (e.g. aliases a1, a2, a3 all Send() the same thing, but a3 checks whether it was sent), this could possibly confuse the script and needs extra flags to be passed and reset. Not impossible, but not a clean solution either. *forgot this originally, added with edit*
How about adding said check and return value to the SendSpecial (with Immediate=True) and SendImmediate functions then? For others, just return eOK since it is a technical impossibility to return it at that point, if I understand properly. | Top |
|
Posted by
| Worstje
Netherlands (899 posts) Bio
|
Date
| Reply #6 on Wed 15 Aug 2007 07:12 AM (UTC) |
Message
| Bump.
(Sorry about seeming/being impatient, it's just that I'm going away for a while and figured a reminder might be useful in the case this topic was forgotten..) | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #7 on Wed 15 Aug 2007 07:42 AM (UTC) |
Message
| Right.
I'll look into that shortly, along with another problem I noticed while I was playing with the toolbar mentioned here:
http://www.gammon.com.au/forum/?id=4951
It seems I can't find out the pixel address of the top left-hand corner of the current world, relative to the desktop.
The function GetWorldWindowPosition returns the location of the world window *relative* to the client space of the main window:
http://www.gammon.com.au/scripts/doc.php?function=GetWorldWindowPosition
The function GetMainWindowPosition returns the location of the main window:
http://www.gammon.com.au/scripts/doc.php?function=GetMainWindowPosition
However the world window is in the client area of the main window (that is, allowing for toolbars, menus etc.) so I can't find out where the world window is on the screen - unless someone has a way?
I wanted to be able to position the custom toolbar just under the start of the world window, automagically, whereever that is. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Onoitsu2
USA (248 posts) Bio
|
Date
| Reply #8 on Wed 15 Aug 2007 11:00 AM (UTC) |
Message
| This is the returned information from the autoit active window info tool, that control id# is the same on all the systems I've run mushclient on, by possibly looking for the handle of that control you might be able to do something.
>>>>>>>>>>> Control Under Mouse <<<<<<<<<<<
Size: X: 0 Y: 72 W: 1024 H: 602
Control ID: 59648
ClassNameNN: MDIClient1
Text:
Style: 0x56000001
ExStyle: 0x00000200
Another approach would be to find the height of the toolbars area, but that can be off by quite a bit, if a person uses toolbars on the side, or has them split between top and bottom. I know this for a fact as I have made a toolbar addon for mushclient that uses UDPSends and has an expandable pane with several buttons that can be renamed and actions set via udpsends as well. And the code to properly place it in the toolbar area is quite twisted and a hack onto of a hack on top of, yup you guessed it, another hack.
It in all honestly is probably the most messed up coding I've ever seen, but it works wonderfully. It might yield some hints or just a push in the right direction, I can e-mail you the source for it, and mark the area with a large comment block.
Laterzzz,
Onoitsu2 | Top |
|
Posted by
| Shadowfyr
USA (1,788 posts) Bio
|
Date
| Reply #9 on Thu 16 Aug 2007 12:54 AM (UTC) |
Message
| I think there is an unwritten rule in Windows API development. Something along the lines of, "If X can be derived from Y and Z, never provide a simple function for returning X, and more importantly, hide Y in some strange fashion, so that all the third party developer has to work with is Z." lol | Top |
|
Posted by
| Nick Gammon
Australia (23,120 posts) Bio
Forum Administrator |
Date
| Reply #10 on Thu 16 Aug 2007 06:25 AM (UTC) |
Message
| I am a bit surprised no-one has asked for this before. The stuff that is already there, while useful, could be more useful if you knew where the client area started. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
35,219 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
top