[Sorry I had to rewrite this, had some copy/paste errors when editing and pasting from scripts.]
Hi all,
Dave's technique is not only good for the screenloc (what he elaborates in more detail), but also when using any *globalLoc* with a scaled stack.
Scale back the globalValue via *dividing* by the scaleFactor:
Code: Select all
-- For example in card script
function globalScaledBack gLoc
put the scalefactor of this stack into sf
return ( round(item 1 of gLoc/sf), round(item 2 of gLoc/sf) )
end globalScaledBack
on mouseUp
set the loc of this stack to \
globalScaledBack (the screenmouseLoc)
set loc of btn 1 to localLoc (the screenmouseLoc)
end mouseUp
Note for beginners. If you need the globalLoc converted to a localLoc, the localLoc function works correctly with a scaled stack (7.0.1), you don't have to 'scale back' the globalLoc for such a conversion (see above mouseUp).
I used such scale-back-computations for determining several sizes in the "nixieStack" (Raspi Collection), that can be scaled by rightClick and moved by dragging (uses 'converted' screenMouseLoc).
My opinion is, that it is a "bug", when we have to use our own globalLoc computations. That is, the scalefactor shouldn't change *global* coordinates, because a screen cannot be scaled, it's a physical unit. Certainly it should change, as it does, change the globalToLocal computations.
I already reported this as a bug without success, now it is at least a documentation bug ...
This (hidden) changing of global coordinates by the engine is also the reason why currently a scaled stack can leave the screen if one is changing the scalefactor and tries to "pin up" the stack at it's current topleft or bottomright or loc, but as I said, no success ...
Hermann