1

I know at a first glance, this will get a duplicate mention. And it very well might be, but I imagine most people are going to think that the answer is similar to this question: Division returns zero

That is not my case. That case, is dividing a smaller number by a larger number integers and getting 0. That makes sense. What's happening for me does not make sense.

Here's my code:

decimal correctedImageWidth = screenWidth / maxColumnsWithMaxSizeImages;

The value for screenwidth, which is an int, is 1024. The value for maxColumnsWithMaxSizeImages, also an int, is 3.

Somehow, correctedImageWidth becomes 0. Which is odd, because 1024/3 does not equal 0, nor would the rounded off number be 0, like the other SO questions had. You'd think I'd get something like 341. Here's proof that the numbers are what I say they are:

Proof

As you can see in my watch. screenWidth is 1024, maxColumnsWithMaxSizeImages is 3. However, dividing these 2 into correctedImageWidth is 0? Is there any reason why I would get 0 from this? I have shown this to colleagues, who are equally as confused. Here's my entire code, perhaps there's something I'm doing? Unlikely, seeing as they're both ints and they both have valid integer values. But obviously there must be something I'm doing? Here's the code:

        int maxColumnsWithMaxSizeImages = (int)System.Math.Ceiling(decimal.Divide(1024, 480));
        if (maxColumnsWithMaxSizeImages < _minimumImagesPerRow)
        {
           .....
        } else if (maxColumnsWithMaxSizeImages > _maximumImagesPerRow)
        {
            ....
        } else
        {
            //between 2 and 4 columns
            var screenWidth = App.ScreenWidth;
            decimal correctedImageWidth = (decimal)((decimal)screenWidth / (decimal)maxColumnsWithMaxSizeImages);
            decimal test2 = 1024 / 3;
            decimal test3 = (decimal)1024 / (decimal)3;
            var test = correctedImageWidth;
        }

UPDATE For some reason, it appears that there was a conflict in my variable declarations. Even though I declared them both in different scopes, for whatever reason it was stirring a conflict. After renaming the variable, I get the corrected value.

Community
  • 1
  • 1
jdmdevdotnet
  • 1
  • 2
  • 19
  • 50
  • 1
    For me, the result is `341`: https://dotnetfiddle.net/AtXbS5 – 15ee8f99-57ff-4f92-890c-b56153 Feb 02 '17 at 19:56
  • So what do you get for `test2` and `test3`? Also, since you are casting to `decimal` you are now doing decimal division. – Matt Burland Feb 02 '17 at 19:56
  • 5
    A [mcve] would make this question really good. – chris Feb 02 '17 at 19:57
  • 3
    Have you tried rebuilding? That screenshot also says `correctedImageWidth` is an integer which wouldn't be the case for the else statement – Sayse Feb 02 '17 at 19:58
  • `test2` is 341 and `test3` is 341.3333333333. I've tried casting to decimal, without decimal, anything you can think of. – jdmdevdotnet Feb 02 '17 at 19:58
  • 1
    I can confirm that I get the correct output of `341`. Your result, along with some sketchy results in your Locals window, makes me think this is an issue with your Visual Studio. Try restarting and testing again. – Abion47 Feb 02 '17 at 20:00
  • 1
    In that watch window in the screenshot, `correctedImageWidth` is `int`. Not `decimal`, `int`. At the bottom of your code screenshot, where the yellow bar is, there's a `correctedImageWidth` that's declared as decimal. In the block above that, yet another `correctedImageWidth` is declared as `int`. How many variables and fields by that name do you have, and what makes you think you're not confused about which is which? – 15ee8f99-57ff-4f92-890c-b56153 Feb 02 '17 at 20:00
  • @Abion47 will do. I have also edited my question to include integers in my original calculation instead of variables. So that people can test. – jdmdevdotnet Feb 02 '17 at 20:01
  • Agree with @chris: I suggest that you remove, step by step, code that isn't necessary for reproducing this problem. Try to find the smallest code that still exhibits the problem. Could be that while you're doing this, you'll discover the reason for it. It could also turn out to simply be a problem with the VS debugger, which has been rather buggy ever since VS 2012, IMHO. – stakx - no longer contributing Feb 02 '17 at 20:01
  • @EdPlunkett the other one is in a different if statement. Only reason it's decimal in mine is trying to make sense of it being 0. – jdmdevdotnet Feb 02 '17 at 20:01
  • 1
    The watch window has an `int`. Not decimal. It says the value `0` is an `int`. You should restart VS and try a clean build. – 15ee8f99-57ff-4f92-890c-b56153 Feb 02 '17 at 20:02
  • 1
    I'm rebuilding and changing the name of the variable. I'll update when I see what happens. – jdmdevdotnet Feb 02 '17 at 20:03
  • I think renaming it is an excellent idea. – 15ee8f99-57ff-4f92-890c-b56153 Feb 02 '17 at 20:04
  • The ended up fixing the problem. Weird! – jdmdevdotnet Feb 02 '17 at 20:15

1 Answers1

5

You've defined the field correctedImageWidth twice, once as int (in the if block) and once as decimal (in the else block).

The screenshot of your Watch window shows the int typed field value, which shows 0 at this point (wasn't assigned since your in the else block). Try watching the decimal typed field, or just hovering your mouse over the other decimal typed field while debugging, it should show you the correct value.

bassfader
  • 1,346
  • 1
  • 11
  • 15
  • 2
    Great analysis, IMHO this is yet another VS debugger bug. It's quite clear from where the code has been stopped that the other `int` variable is out of scope, so the debugger shouldn't display *that*, but the one that is in scope instead. – stakx - no longer contributing Feb 02 '17 at 20:03
  • @stakx yes exactly. – jdmdevdotnet Feb 02 '17 at 20:03
  • 2
    The reason this was already posted as a comment (twice), is because it is just a guess which isn't useful as an answer – Sayse Feb 02 '17 at 20:04
  • @Sayse: The guess could potentially be turned into certainty. The OP could try renaming the `int` variable by the same name to another, unique name. If that resolves the issue, then we know the guess was correct. I would also suggest restarting VS just to be sure it doesn't cache some outdated debug symbols. – stakx - no longer contributing Feb 02 '17 at 20:06
  • 1
    @Sayse This is not a guess, where exactly did I guess in my answer? This is an observation based on the screenshot posted in the question, which clearly shows what I am stating here. The field is defined twice, and the field beeing watched is the `int` typed (from the `if` block) while the OP is currently debugging the `else` block (where the field is also defined as `decimal`). I only suggested a possible method for the OP to analyse and confirm that ("Try ..."), but that's not a guess... The comments haven't even been there when I started typing the answer... – bassfader Feb 02 '17 at 20:12