Mouse Control PRocedures don't work

ID:100678
 
Aug 21 2010, 6:17 am
BYOND Version:474
Operating System:Windows XP Home
Web Browser:Internet Explorer 8.0
Applies to:Dream Maker
Status: Unverified
Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
Simple, Mouse Control parameters don't work, period. I used params2list on them, nothing. I even just displayed the parameter to the usr to test it out, and this is what I got:

mapwindow.map

mapwindow.map

mapwindow.map
Numbered Steps to Reproduce Problem:
1. Use any Mouse proc
2. Use parameters

Expected Results:
An actual list of the params

Actual Results:
Some random stuff that is quite irrelevant to the actual expected result, which is a text string showing the parameters.. simply "icon-x=blah;icon-y=blah;screen-loc=blah"

Aug 21 2010, 6:34 am
Can you please provide a code snippet that demonstrates this problem?
Aug 21 2010, 6:42 am
I was going to... but I figured that 3 lines of code, a map, and any clickable icon would be easy for one to do on his own.

atom/Click(location,control,params)
 world<<params
turf/icon='white.dmi'//Just make an icon, mines is white
Aug 21 2010, 6:43 am
it should didsplay "icon-x;icon-y;left/right/middle;screen-loc"

but it displays "mapwindow.map"
Aug 21 2010, 6:51 am (Edited on Aug 21 2010, 6:59 am)
This is not a bug, you are just using the parameters incorrectly.

atom
    Click(atom/t, control, params)
        params = params2list(params)
        var/pixelx = text2num(params["icon-x"])
        var/pixely = text2num(params["icon-y"])
        world << "([pixelx], [pixely])"
Aug 21 2010, 7:10 am
Why did it display two different things when i used it on two different computers then?

In fact, Ss4Toby's mouse demo(which uses 4.0 Mouse procs) didn't work

EDIT: Same code, different version of BYOND, I used my code before, and it worked perfectly, then I updated, and it didn't function at all.
Aug 21 2010, 8:59 am
You'll have to provide a demo project that shows this in action. Trying to reproduce this myself resulted in the expected behavior.

I suspect the issue is not a bug, but rather that your project, or a library it depends on, has overridden client/Click() in a way that is not passing arguments correctly to the rest of the click function.