mIRC Home    About    Download    Register    News    Help

Print Thread
SendMessage WM_MCOMMAND behavior #239660 13/11/12 07:24 AM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
The WM_MCOMMAND message to the 'SendMessage' function has the wrong default behavior. The behavior should default to script commands by default, not sending messages to a channel.

Repro steps:
1) Write 'window "status window" 0 0 100 100' to a memory mapped file named "mIRC".
2) Call 'SendMessage( hwnd, WM_MCOMMAND, 0, 0 )' in the 'user32' system DLL.

The text is sent to the active window instead of executed.

The change might break existing code. Therefore, a new 3rd message to preserve backwards compatibility might be better.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239661 13/11/12 08:44 AM
Joined: Jul 2006
Posts: 3,702
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,702
Technically, this is undefined:

Originally Posted By: /help SendMessage
cMethod - how mIRC should process the message, where:
1 = as if typed in editbox
2 = as if typed in editbox, send as plain text
4 = use flood protection if turned on, can be or'd with 1 or 2
8 = use unicode text
You are using 0. Perhaps what you are looking for is a feature request


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: SendMessage WM_MCOMMAND behavior [Re: Wims] #239665 13/11/12 09:13 AM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
No, in that context, 0 has the meaning of "none of the above" referring to the flags, which means "process as a command", not "as if typed in editbox".

The docs for WM_MEVALUATE imply that 0 is an option. Therefore if 1 and 0 behave the same for WM_MCOMMAND, the docs should indicate it, especially given the name of the message constant and the heading of the section.

Either the behavior should be changed or the docs should. What is the appropriate forum for reporting discrepancies in the docs please?

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239666 13/11/12 09:39 AM
Joined: Jul 2006
Posts: 3,702
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,702
The help file is very unclear about that, imo it's not really implying you can use 0 either when executing a command or when evaluating a line.
I agree though, it should be possible not to use a value (or a value representing 'none of the above'), at least when executing a command, because there are difference when a command is executed from the editbox or not.
You can use this forum to report a problem with the docs.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: SendMessage WM_MCOMMAND behavior [Re: Wims] #239678 13/11/12 08:20 PM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
I think "as if run from a script" would be the salient behavior. If 0 should do that, it's a bug. If another flag should do it, it's a feature request. If nothing should do that, the docs are misleading.

There is an element of humor in sending a message with the default behavior of SendMessage.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239705 15/11/12 09:22 AM
Joined: Dec 2002
Posts: 4,733
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,733
Thanks for your bug report. The WM_MCOMMAND was added to mIRC to enable applications to simulate entering text in the editbox of a window in mIRC. The "1 = as if typed in editbox" option is in fact the default. I have added "(default)" next to this item in the help file to make it clearer. In order for text to be processed as a command, you would need to use the / command prefix, the same as in an editbox.

Re: SendMessage WM_MCOMMAND behavior [Re: Khaled] #239712 15/11/12 09:45 PM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
IMHO, the "simulate entering text" behavior should be a different message, such as WM_MENTERTEXT. The command prefix can change from instance to instance, but the "say" command doesn't, therefore it's more reliable to prefix "say" than a slash or whatever character; and the name of the message, WM_MCOMMAND, implies that the contents will be executed as a command.

However, my use case might not be typical, such as if most other IPC applications aim to simulate the editbox, not run commands.

The addition to the docs might have prevented my mistake, and might do so for others; all I did was "spam" a channel with 4 script commands. IMHO, what Khaled said,
Quote:
In order for text to be processed as a command, you would need to use the / command prefix, the same as in an editbox.

would be a much more helpful addition. But I'm satisfied with that.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239714 15/11/12 10:40 PM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I think it should execute by default too, but it's too late for this change as dlls already depend on the current behaviour. A help file change is pretty much the best that can be done.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: SendMessage WM_MCOMMAND behavior [Re: argv0] #239725 17/11/12 11:02 PM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
I disagree with the idea of "too late" in most cases, especially software. All that's required is sufficiently advanced warning. Perhaps the docs could say, "Will be changed to the WM_MENTERTEXT message starting in version 7.5; use '/say' to obtain the current behavior."

Furthermore, as the interaction occurs entirely numerically, the value of the constant can be left the same, and merely the name changed, interfering only with readability of legacy code and no functionality whatsoever. Then the proper WM_MCOMMAND could be added as WM_USER + 202.

But yes, the docs could be much clearer regardless, in that entry, and the rest of the docs overall. Let me know if I'm beating a proverbial dead horse here.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239730 18/11/12 12:45 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Feel free to disagree, but this isn't really a matter of debate-- Khaled's policy on avoiding backward incompatible changes has been very clear. You're handwaving on the advanced warning thing, and I'm afraid you don't really comprehend the connotations of making backward incompatible changes in mIRC. There are hundreds of undermaintained (or completely unmaintained) dlls and scripts in mIRC that rely on mIRC to work as it was originally designed (+/- legitimate bugs). I personally have authored at least 4-5 dlls that rely specifically on WM_MCOMMAND and have not been updated in >3 years. I don't plan on updating them, because they are stable. Users should not have to make the choice between using the dlls they want and upgrading their copy of mIRC. Unfortunately the reality of small throwaway IRC scripts lends to the creation of a lot of unmaintained code. This is not a problem with mIRC as a community, it just means the old working scripts are stable and don't need to be touched. Khaled understands this very well, and we don't need to mess with this balance.

As far as making another constant goes, this is a little bogus-- if you're making changes in your own code, you can just as easily make the change to prefix your command with "/". If the name is confusing to you, nothing is stopping you from #defining it as WM_ENTERTEXT yourself and creating a helper script for your "proper" WM_COMMAND functionality. Most SendMessage code I've seen is wrapped up with this helper functionality already, anyway.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: SendMessage WM_MCOMMAND behavior [Re: argv0] #239887 30/11/12 06:14 AM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Mr. Argv0,

First of all, regarding my "advance warning" strategy, it has a lot of potential. Some problems need a "shock treatment", an imminent threat of new requirements for compliance, but some problems need slow change, so that the participants can "plot" a course to incorporate it, in this case for their software, but in IRL cases, for their lives. It is the difference between 5 minutes' warning of an obstruction, and an hour's warning.

Secondly, you are obstructing discussion on this thread and in this forum. I included the option to preserve binary compatibility. So your statements merely obscured mine; you did not contribute or argue. Please refrain in the future.

Thirdly, your idea to "just as easily make the change to prefix your command with '/'" isn't generic. It only works in some cases on some installations. Please show respect for those who use another command prefix in the future.

Thanks to everyone for your patience with me revisiting a few weeks old thread.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239888 30/11/12 10:07 AM
Joined: Jul 2006
Posts: 3,702
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,702
argv0 might not be the kindest person on this forum, he still know what he is talking about, here you're the one attacking him with nothing but your misunderstanding: the / character stays the default command prefix regardless of what you are using in the option, use that with '1' and you will be fine, it's not like you can't have the expected behavior because of a bug that won't be fixed because of backward compatibility, which is much more annoying.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net
Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239891 02/12/12 04:53 AM
Joined: Oct 2003
Posts: 3,918
A
argv0 Offline
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
As Wims pointed out, / is always the command prefix. It is a hardcoded value. The "Command Prefix" set in Alt+O -> Other is actually an alternate prefix; it does not change "/". So "/" is guaranteed to work in all cases.

I did not obscure your points about binary compatibility. I responded to the idea of using a new constant. There is little actual benefit in adding a new constant, since, as I pointed out, most SendMessage code is wrapped up in a helper function that is written once (there is lots of setup code), and you can #define whatever constant name you'd like. At its root, this is just a documentation issue-- the currently named constant is a little misleading. That's all. Call it WM_MEDITBOX if you think WM_MCOMMAND is inaccurate, but mIRC shouldn't need to care.

And finally, advance warnings only work if people are listening for those warnings and adjusting accordingly. You missed the part where I described the reality of our community: there are lots of scripts that are unmaintained. Some popular scripts/dlls like MDX and DCX have been unchanged in over 5 years and yet are still used by tons of people. You can give 100 years of warnings and it won't get these authors to update their DLLs. Khaled made the right decision to build a client where a user can write code once and expect it to work for the foreseeable future of the client, since the vast majority of these scripters are not paid to write or maintain their code-- and in some rarer cases, not even that knowledgeable about how to maintain their code. No backward incompatible changes is a good strategy for such an audience.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Re: SendMessage WM_MCOMMAND behavior [Re: argv0] #239894 02/12/12 07:21 AM
Joined: Apr 2010
Posts: 59
A
ascription Offline OP
Babel fish
OP Offline
Babel fish
A
Joined: Apr 2010
Posts: 59
Mr. Wims's post was most informative; but the description of the Options > Other entry now seems misleading, but the original topic seems more generally applicably accomplished.

Mr. Argv0,

You are experiencing conflicting priorities. One one hand, you feel, "you promised". On the other hand, you feel, "change". The discrepancy is responsible for nostalgia in some cases and panic in others. This is normal; and I appreciate your efforts towards less "obfuscating" content this time. Thank you for your effort and contribution.

Any maintainer of software has a responsibility to both; and consequently must balance and include both in his or her decisions; and not neglect either. You are advocating neglecting change, Mr. Argv0. Some DLL's should become disfunctional over time; not all, but some.

So we're clear, my proposal did not require a binary incompatible change, but it is also being discussed. The staff have my permission as the OP to relocate this thread to that end.

With the WM_COMMAND window message, most people would expect the string, "echo -s $time" to cause the indicated command to be executed. Most people would expect e.g. a WM_SENDTEXT window message to cause the string "echo -s $time" to be sent to the active channel as text.

Either the docs should indicate this aberration very clearly, or the window messages should be renamed, optionally in compliance with existing binary code. That is, assuming that mIRC should be available to the public, and not require newcomers to jump through hoops, for the mere half-baked thrill of more senior users, which might not be the case; it is not my decision. The thrill we feel is just empathy with people's hopes being crushed regardless.

And furthermore, it's eminently possible that you, Mr. Argv0, are merely playing devil's advocate, but also possible that I'm projecting and you're actually misinformed about the nature of change. By all means, be my guest, please clarify.

Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239896 02/12/12 02:14 PM
Joined: Oct 2004
Posts: 8,330
Riamus2 Offline
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I would prefer only a clarification in documentation. What "word" you use for the command is irrelevant. It doesn't really matter if you assume that it means something different. The command could be called "WM_GO" and it would be work the same way. The edit box is also called a command line, so it makes sense that WM_MCOMMAND is treating the text as if you're sending the same thing from the "command line". And if you send something from the command line without a / or alternative command character, then it will be treated like text. I really don't see why this is such a problem to understand.

In the end, think about what you are suggesting... You want the syntax to change so it makes more sense to you. This offers no real benefit other than that you think it makes more sense. And it can easily cause scripts to stop working. So it offers no real value and breaks existing scripts that people rely on. That's not a good option. Using your wording, a maintainer of software has a responsibility... he or she needs to look at the benefit of making a change compared to the problems caused by that change. And there just isn't anywhere near enough benefit to warrant this kind of change. As it's been pointed out, / always works regardless of settings and that was your only real reason why it should change.

Could this be done without breaking any scripts or DLLs? Perhaps. But does it offer any real value? Not really. So is it worth the time to do it? No. You talk about making new users "jump through hoops." Consider this... new users to the language already have to learn the language and learning what WM_MCOMMAND means isn't any different than learning what $gettok() means or any other part of the language. On the other hand, old users (of the scripts, not old scripters/programmers) already have working scripts. A change that breaks their script will force THEM to "jump through hoops" just to get their scripts working again. You'd be forcing far more people to "jump through hoops" by breaking existing scripts. And the reality is that a very large number of users don't script, but use old scripts that are no longer maintained, but which still do what they need. There has to be a real good reason to make a change that can break scripts and syntax isn't a good reason.

Just because you assumed that COMMAND meant "EXECUTECOMMAND" doesn't make it bad. A simple clarification in documentation would resolve this very well without affecting any users. That's what I would recommend.


Invision Support
#Invision on irc.irchighway.net
Re: SendMessage WM_MCOMMAND behavior [Re: ascription] #239900 02/12/12 08:19 PM
Joined: Dec 2002
Posts: 4,733
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,733
The above posts more or less capture what I have previously stated as my views on backward compatibility. I try not to make changes that break older scripts. I will often even leave non-critical scripting-related bugs in place if they were introduced many years ago. In the case of WM_MCOMMAND, which was added to mIRC v5.9 in 2001, this is the first time anyone has asked for it to be changed. Unfortunately, I cannot change a feature that has been established for so long. I have received many emails over the years from people who enjoy using, and depend on, scripts but have no idea how to update them. It can be such a difficult and frustrating experience for users to ugprade to a new version of mIRC only to find that their scripts are broken. So as a policy, I try to avoid making non-backward compatible changes unless they are necessary. Thanks for your comments everyone.