Forum

Hi,

I’ve been trying to implement a cell editor for 64-bit (double) floating point values in a CExtPropertyGridCtrl. The properties I’m working with have arbitrary precision based on the type of property I’m dealing with. I’d like to use the CExtGridCellUpDown class for my implementation due to the ease with which values can be altered via the mouse wheel or up/down keys.

I’ve come across two basic problems:

1) Due to FP precision issues, the default CExtGridCellUpDown implementation looks buggy to the user (even though it isn’t) because values may not appear as they expect. For example, in the ProfUIS-Controls Grid sample type 10.312 into row 2 of the ’UpDown’ column (or Variant col) and start decrementing the spinner. When it hits 0.312 it actually displays 0.319999999999999 (which to the user looks like 99999999999 because they can’t see the leading part of the number).

2) There’s no fixed precision. At times I’d like a set number of places after the decimal point, which looks tidier anyway when spinners are being used. Even more problematic for me is that decimal values which lie on an integer boundary display as integers (i.e no decimal point shown) which means there is often no way for a user to distinguish a float property from an int.

The way I tried to solve this was to do the following:

a) When Apply() is called on my CExtPropertyValue class, format the Variant->dblVal myself using _snprintf to get the precision I want
b) Call atof on the resultant string and set the inplace Variant->dblVal (and ValueActive) to the returned value
c) Call TextSet on the inplace control and ValueActive with my formatted string

This has solved the precision problems with the spinners, but the inplace cell is still truncating any trailing zeros and still removing the decimal point if the double value happens to be an integer.

So, that’s my question: How do I force the grid cell to display a decimal point and as many places as I want after the decimal point? Is there an easy way? Or can I somehow use the CExtGridCellNumber class with up/down spinners, including keyboard/mouse wheel functionality?

Thanks for your time.

Okay, I’ve now got the functionality I need by using the recommendation you made in your first reply - using TextGet() to do the formatting. I’ve extended CExtGridCellString with the up/down buttons as a bool property which means I can use this class for all my floating point properties, irrespective of whether or not spin buttons are required. For mouse wheel and keyboard functionality I simply cut and pasted the code from the CExtGridCellUpDown source.

I’d already tried to implement the class in this way before I contacted support, but I couldn’t understand why the inplace cell text wasn’t updating when I called TextSet() with my formatted string.

A final point about some odd painting behaviour I came across (not just in my class but in the vanilla CExtGridCellUpDown):

Let’s say I have a CExtGridCellUpDown in a property grid and the user increments the value with an ’up’ spin button. The user then clicks undo from the toolbar. I have to implement that undo with the minimum of effort, and so I followed some advice you gave in another thread about using OnPgcQueryGrids() to locate the relevant cell and change the value. This works fine, but when the cell is updated and repainted, the ’up’ spin button now draws in its pressed state (darker colour). Nothing you now do will change that pressed state until you actually press the button again. You can go to another cell to remove focus, but when you return the button still paints as pressed. It’s even possible to make both buttons paint as pressed simultaneously by decrementing the cell value and then calling undo again.

There may be some simple explanation for this, but I simply hacked a fix by calling...

pCellDst->ModifyStyle(0, EGCS_PRESSED_UP);
pCellDst->ModifyStyle(0, EGCS_PRESSED_DOWN);

...in my cell update method. All the same, if I’m doing something wrong please let me know.

Cheers,

Andrew

Thanks for your efforts and response on this, guys.

I’ve been on vacation for the last three days which is why I didn’t respond earlier to your replies. I’ll be looking at this in detail again on Monday, but at first glance the solution you’ve come up with is an excellent one. The class hierarchy is far more logical and comprehensive now.

Again, thanks for your support.

In response to your request, we did the following:

1) changed the base class of CExtGridCellUpDown to CExtGridCellNumber
2) moved the functionality of CExtGridCellUpDown to CExtGridCellVariant so this functionality is now available in all the derived cell classes including CExtGridCellNumber.

You can turn on the up/down functionality in CExtGridCellNumber by applying the __EGCS_BUTTON_UPDOWN cell style. If you need this update right now, please contact us via email.

1. Actually we do not use some specific realization of double values operations. The CExtGridCellUpDown() class is based on the VARIANT type and all the operations are performed using the VARIANT API.

2. Did you try the CExtGridCellNumber::SetNumDigits() method? You can override the CExtGridCellUpDown::TextGet() method and implement your formatting yourself.

3. Yes you can create your own class derived from CExtGridCellNumber and copy two virtual methods there, which you can find in OnInplaceControlPreTranslateMessage() and _DoValueIterate(). Do not forget to apply the __EGCS_BUTTON_UPDOWN cell style.

So, it seems you need to create some CExtGridCellNumberUpDown class. Actually, after answering your questions we decided to add such a class into Prof-UIS ourselves. So please let us know your thoughts.