I thought Canvas.Scroll is not working but I was wrong

I have a weird issue here while converting iClip into a 64 bit app that I build with 2019r1.1:

I am calling Canvas.Scroll, which usually works: As a 32 bit app, and even as 64 bit as long as I run in Xojo’s debugger.

But when I build the 64 bit app and run it (standalone), the call of Scroll() appears to remove all scrolled controls entirely.

I don’t see how I could be doing something wrong because when I run the same in the Debugger, it works as expected.

Is this a known issue?

better not be or the IDE wouldnt work very well :stuck_out_tongue:

Check your code for debug #if’s and for variable overflows?

Oh, it’s something totally different. It’s indeed a long-standing and never-before-occuring bug in my code.

Had to add DebugLog calls to figure this out.

Who can identify the bug in this code:

[code]Private Sub myScrollTo(newX as Integer, newY as Integer)
if newx < 0 then newx = 0
if newy < 0 then newy = 0

dim w as Integer = me.HorizontalStepAmount ’ width of a bin with gap
dim h as Integer = me.VerticalStepAmount ’ height of a bin with gap

dim oldX as Integer = me.currentHorizontalScrollPosition
dim oldY as Integer = me.currentVerticalScrollPosition

dim dx as Integer = oldX MOD w - newX MOD w
dim dy as Integer = oldY MOD h - newY MOD h

Scroll (dx, dy)
End Sub[/code]

Hint Scroll did what it should. My description that the scrolled controls appeared removed might be an indicator of what went wrong.

https://documentation.xojo.com/api/math/operator_precedence.html

Well, Julian - what do you think went wrong? :slight_smile:

The thread title reminds me of the saying:

“Once I thought I made a mistake. But I was wrong.” :slight_smile:

mod is supposed to be higher precedence than + and - so that expression should be treated like

dim dx as Integer = (oldX MOD w) - (newX MOD w)

without the need for parenthesis

I’m guessing you got the MOD 0 bug :slight_smile:

The control went reaaaaaaly far to the right, 0 Mod 0 != good

Yep, well spotted, Norman and Julian.

In my code, either h or w was ALWAYS 0, but until now, this never caused a problem - the MOD operation always resulted in 0. Of course, MOD 0 is undefined, so I’m not surprised this leading to the effect I saw. What surprises me is that this didn’t surface earlier, not even in 64 bit within the debugger.

And Norman, the parentheses are for better readability. Also, since the ObjC compiler started giving warnings when you combined && and || without using parens, I default now to it. Doesn’t hurt, right?

Yeah ?
Are you saying this that changed from 32 to 64 bit ?
I almost wish that MOD was defined as [quote]N mod 0 => N[/quote] but …

that does seem surprising

[quote=456120:@Thomas Tempelmann]
And Norman, the parentheses are for better readability. Also, since the ObjC compiler started giving warnings when you combined && and || without using parens, I default now to it. Doesn’t hurt, right?[/quote]
Not at all
Code clarity is, or should be, a high priority for everyone but I know some like to write really terse code

Yes. As this code was in there for years, and either h or w was always 0, so at least in 32 bit builds (which were all iClip versions until now) the “… MOD 0” op always resulted in zero. Otherwise, the clip bins would have shifted sideways, which would have been noticed.
I might be wrong, but at least this issue only surfaced now, when building for 64 bit, where it occurs practically every time (with “x MOD 0” resulting in random large values).

huh
none of the existing bug reports note this behaviour change that I can see
<https://xojo.com/issue/11536>
<https://xojo.com/issue/42220>
<https://xojo.com/issue/56395>

but indeed this simple code when run as 32 bit gives a different result than in 64 bit

Dim a As Integer = 3
Dim b As Integer = 0
Dim c As Integer = a Mod b

break

EDIT : <https://xojo.com/issue/57676>
seems a bad thing to get sudden silent behaviour changes like this :stuck_out_tongue:

And here is another related one, again showing differences in behavior in 32/64Bit:
<https://xojo.com/issue/55370> - NaN (Division through 0): Different behavior and comparison results in Target32Bit and Target64Bit