OnPluginMXPcloseTag may have a wrong intention of its use

Posted by Maxhrk on Fri 11 Jun 2010 06:20 PM — 5 posts, 28,281 views.

Maxhrk USA Fri 11 Jun 2010 06:20 PM #0

Here my function that i use for my testing purpose before i actually use it for something else like checking prompt, etc.

however, i noticed during testing that it has unexpected result that contrast what has said in the document about what OnPluginMXPcloseTag will give in its variable.

function within my plugin:


function  OnPluginMXPcloseTag(name, text)
	local name = name
	local text = text
	Note(type(name))
	Note("NAME:" .. tostring(name) .. "TEXT:".. tostring(text))
	if name == "PROMPT" then
		confirm = string.find(text, "^(%d+)h, (%d+)m, (%d+)e, (%d+)w (c?e?x?k?d?b?)-$")
		if confirm then
			Note("I got you!")
			return
		end
	end
end

with that mind, i should have got the prompt line in text variable like this:


<PROMPT>3310h, 2605m, 14400e, 14400w exk-</PROMPT>

however, the result differs from my expectation when it show the variables in name and text content:


NAME:prompt,3310h, 2605m, 14400e, 14400w exk-TEXT:nil

So, I assumed there may be a bug on your hand, Nick.

Shadowfyr USA Fri 11 Jun 2010 08:23 PM #1

Actually, no, its working as expected. Its intended to ID tags like, say:

<smudge amount="234">

Where Name = 'smudge' and Text = 'everything else', in this case 'amount="234"'. The only "bug" per say might be that it would have been easier to work with this if an attempt had been made by the function to generate a table or any attributes + values that "appear" to be in there. Just to make things less annoying, instead of forcing you to parse all the stuff after the name yourself, in an attempt to figure out what the heck it all is. But, that is more of an "ease of use" issue, than a bug, per say.

Maxhrk USA Fri 11 Jun 2010 09:17 PM #2

i think you are probably thinking OnPluginMXPopenTag but not the closeTag. Here what the document has to say about OnPluginMXPcloseTag



MXP end tag

This routine is called when an "end" tag is parsed (successfully). For example, "</send>".

Inside a plugin: OnPluginMXPcloseTag

Some tags, marked as EMPTY, do not have end tags.

The arguments are:

1. Tag name, eg. "send"
2. Value of "&text;" variable. In other words, everything that appeared between the start tag and the end tag. This is limited to 1000 characters maximum.

For example, if you had:

<send>eat newspaper</send>

The value of &text; would be "eat newspaper".


function OnMXPEndTag (name, text)
  AppendToNotepad ("MXP", "Closing tag: " .. name .. "\n")
  AppendToNotepad ("MXP", "Text: " .. text .. "\n")
end -- function

hence, what i am expecting is "100h, 100m, 100w, 100e" in the text in OnPluginMXPcloseTag, not OnPluginMXPopenTag.

Nick Gammon Australia Forum Administrator Fri 11 Jun 2010 09:28 PM #3

The documentation is wrong, or at least, misleading.

See this: http://www.gammon.com.au/forum/?id=9669

It is correct if you have the "close tag" callback in the main world script. In a plugin, it lumps together the name and text into a single argument.

So you need to break up the first argument at the first comma (in case there are more than one comma). Before the comma is the name of the tag, after the comment is the "tag contents".

You can see it here in the code (around line 192):

http://github.com/nickgammon/mushclient/blob/master/mxp/mxpClose.cpp

Notice how the tag name and tag contents are sent separated by a comma.

There was some reason I did it this way, I think laziness in trying to make a whole heap of helper functions for plugins to handle all sorts of different argument patterns. I'll fix up the documentation.

Maxhrk USA Fri 11 Jun 2010 10:19 PM #4

ok, thank you very much for answering the question that bothers me. Now, I can fix my code. heh.