Discussions

W3bbo said:

ploe said:

*snip*

Can you post your code?

I'm an idiot. I couldn't find the bug because it wasn't in the window's code, but our base class that it extends. The other windows where the title update does work inherits a different base class.

In our base class we disabled painting while the window was in a state of populating data (because we were getting flicker) with this line:

SendMessage(this.Handle, WM_SETREDRAW, 0, IntPtr.Zero);

We re-enabled painting when it is done populating with this line:

SendMessage(this.Handle, WM_SETREDRAW, 1, IntPtr.Zero);

Then we call Invalidate(true). But that just invalidates the client area, not the non-client area, hence why the title bar was not re-painting.

Solution:

Invalidate and paint the ENTIRE window by calling: InvalidateRect() and then UpdateWindow().

Sorry for the wild goose chase.

W3bbo said:

• Is the .Text property being set on the same thread that instantiated the form?
• Set a breakpoint to make sure it's been hit
• Make a copy of your form's code and reduce it down until you get the smallest amount of code that reproduces the problem, then compare it to a working sample.

I can't seem to find a different between the windows.

I have a method called UpdateTitle() that actually updates the Form's Text. InvokeRequired always returns false, so it's definately not in the wrong Thread. Nothing related to this window is multi-threaded so this was not surprising.

When I put in a breakpoint, the title does update. I suspect that's because Visual Studio takes focus and when I go back to the window, it triggers a re-paint of the non-client area. The title change also shows up if I minimize, then maximize the window.

I have this one window where when I set the Text property of the Form it does not update the title bar. I am 100% sure my code is being called and the Text value is being changed. It's just not physically painting it on the screen.

I have about 100 or so Forms and this is the only Form that does this. I've compared properties with a window that does work and can't see anything odd that I'm doing in the broken Form. Has anyone run accross this or have an idea of things I can check?

Dexter said:

ploe said:

*snip*

 

Yes, it can. But try -78.884687963873147 instead. Or -78.884687963873143

 

The last digit is kind of bogus.

You're right! Those other values don't work. The '8' is bogus and it appears as though the '4' is also non-existent. Do you think it's just an odd behavior of the debugger?

Dexter said:

ploe said:

*snip*

Wait a moment, where did that value come from anyway?

 

It has 17 significant digits and that's more than double can represent. Is that a constant in your code? In that case you need to make it a decimal in the first place. Like:

 

const decimal x = -78.884687963873148m;

 

Note the m suffix. That tells the compiler it is a decimal literal. Otherwise double is implied.

 

 

It's definately a double, I got the value from the assembly as a double with that value in it. I've just been using a constant in my posts so that it's more understandable.

If you put that value in your watch of VS it does say the type is a double.

It's all a little confusing. If you run this bit of code you see that a double can store this value:

double d = -78.884687963873148;

Console.WriteLine(d.ToString("R"));

W3bbo said:

ploe said:

*snip*

I think that's because Decimal's ToString() method by default truncates the results.

 

Try working with Decimals throughout your program though.

Unfortunately the double comes from an external assembly.

(-78.884687963873148M).ToString() is not truncated though, so I feel like I'm losing data in the typecast.

The only thing that seems to convert it correctly is if I do this:
decimal d = Decimal.Parse((-78.884687963873148).ToString("R"));

...not exactly efficient.

W3bbo said:

phreaks said:

*snip*

http://sine.codeplex.com <-- My arbitrary-prescision library for .NET; note that I did some major refactoring in the latest revision and my code is unstable, unusable, gives inaccurate (if not just plain wrong) results, and is otherwise unfit for purpose. Use with caution. The earlier revisions (and the available download release) still work fine.

 

http://intx.codeplex.com <-- An integer-only library for .NET far, far superior to my own... but only does integers. The IntX class in this library is superior to the BigInteger class in .NET4.0 in most circumstances, so it's worth checking out.

 

EDIT: I see that F# comes with its own BigRational class. Note that it's a rational number (that is, any number representable by an integer numerator and denominator) so whilst it will always give you 'purer' results than a floating/decimal library like mine it won't necessarily be faster.

Okay I seem to have grasped a better understanding of the problem I'm running into:

The initial type I have is a double with the value -78.884687963873148. I typecast it to a decimal because I need slightly more precision on it based on the math I'm going to do. But typecasting the double -78.884687963873148 to a decimal, I actually lose precision.

(decimal)-78.884687963873148 = -78.8846879638731

:/

When I run this bit of code '-78.884687963873148 * Math.Pow(10, 13)' it returns the value: -788846879638731.5. I would expect it to return -788846879638731.48. Is there an alternative to the way I'm doing it above to get it to return the expected value?

Is there a way to deprecate a C# class that isn't in my assembly?

In our assembly, we have our own implementation of what the built in MessageBox class. It's called PopupBox. I'd like to discourage the use of MessageBox in our application. I thought a good way would be to make MessageBox deprecated so that it threw a compiler warning.

If this isn't possible, can you suggest an alternative?

cdwatkins said:

Your talking about a contra/co- variance problem.  The problem is that IList<Bob> isnt assignable to IList<Person> even though Bob is a type of person.  They fixed this problem in .NET 4.

Probably not the solution you are looking for, but you could do this:

Have only one Customer class and make your 'special' members internal so only you can use them. If it's in a different assembly from where you need it you can use this to gain access to the internal members: http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx