Formatting currency/decimal fields when in edit mode

I'm displaying a number of currency (decimal) fields in a grid. I'm using the format "C" in order to display the values as localised currencies (56.7 is displayed as "$56.70"), and this works fine.

In edit mode, however, it is a different matter.

When I tab into the field, it shows all of the zeros/decimal places in the number, so 56.7 is displayed as "56.7000000000000000". Not at all a practical way to edit the data.

What I would like is for it to display data while in edit mode dependent on the current value.

For example:
10 would display as "10.00"
23.4 would display as "23.40"

45.67 would display as "45.67"

12.345 would display as "12.345"

I had a play with the standard maskInput options, but none of them seem to suit my needs.

I suspect there is no easy way of doing this, and will probably have to format the data myself somehow, but I have no idea where I have to do this. If someone can tell me how to do this, or at least point me in the right direction, I'd much appreciate it.

thanks.

—Edited to fix up formatting issues (Google Chrome browser doesnt work quite right with this forum…)—

It looks like you are probably using 0's or #'s in your mask. Try using n's, instead.

Like "nn.nnnnnnnnn"

 Thats not quite what I'm after. The formatting of my original message was all messed up (I'm blaming googles new browser for that), which probably made it difficult to see what I wanted.

If I use a MaskInput of "nn.nnnn", then it will display 12.3 as "12.3000" (in edit mode), whereas I want it to display as "12.30" (in edit mode). So I guess the rules of what I want to display (while in edit mode) are:
1) Display a minimum of 2 characters.
2) If value has more than 2 decimal places (say, 12.345), display the minimum number of decimal places to see the value in perfect accuracy (no trailing zeros).
3) Allow the user to add additional decimal places (change 12.345 to 12.3456).

Changing the MaskInput to "nn.nnnnn" does not quite do this. It will display that number of decimal places every time (in this case, 5), and not all the user to put a sixth in. So 12.345 will display as 12.34500, and will error if  the user tries to change it to 12.345678.

There's no way to do this. The mask functionality doesn't have the capability to have variable-lengths like that. I would think that using n's instead of 0's or #'s would mean that the trailing 0's were left out. I guess I am wrong about that. But there's definitely no way to create an arbitrary minimum of 2 digits after the decimal while still allowing more to be displayed in some cases.

 I have done a little research, and read a bit about a DataFilter, which might be able to help. Is this the case, or am I just clutching at straws?

 I managed to get the DataFilter thing working for grids, but from what I can tell, it seems to add a lot of overhead to drawing/formatting. So much that that it takes to scroll through records is two to four times as long.

 Is this to be expected? Is this just the nature of DataFilters? Or am I doing something wrong?

If it's slowing things down, then my guess is that your DataFilter is hitting exceptions that are being handled by the grid, or else the DataFilter code is just very inefficient. It would have to be really bad for it to be noticable, though, so I suspect it's probably an exception. Set the Visual Studio IDE to break on all run-time exceptions to see if any are occurring. 

I looked for run-time exceptions (as you suggested), and it found none. So the overhead must be elsewhere.

As an experiment, I set up a DataFilter which returns null (so it doesnt actually do anything). When I tried scrolling thorugh records, it slowed down the scrolling by more then a half without any datafilter (Or is that less then half? Well, slower then half the speed).

Which leads me to think I'm not setting the datafilter right in the first place. The examples are kind of light on the ground, so I had to improvise.

What I have done:

1) Create a new class, that looks a little like this (I am returning null right now):

  818     public class GridCurrencyDataFilter : Infragistics.Win.IEditorDataFilter

  819     {

  820         /// <summary>

  821         /// Converts Currency fields for display in edit mode

  822         /// </summary>

  823         /// <param name="conversionArgs">Input arguments.</param>

  824         /// <returns>Converted data.</returns>

  825         public object Convert(Infragistics.Win.EditorDataFilterConvertArgs conversionArgs)

  826         {

  827             return null;

 2) When the user opens a form, the code is cycling through all of the columns in all the bands of the UltraGrid. Any that it finds have a format of "C" (for currency) it is applying this datafilter:

       private void SetDataFilters(UltraGrid ugSender)

        {

            foreach (UltraGridBand ugBand in ugSender.DisplayLayout.Bands)

            {

                foreach (UltraGridColumn ugColumn in ugBand.Columns)

                {

                    if (ugColumn.Format == "C" || ugColumn.Format == "c")

                        ugColumn.Editor.DataFilter = new GridCurrencyDataFilter();

                }

            }

        }

 Thats it. Even with it working like this (with the DataFilter returning null) it is noticably slower than without any datafilter. Am I setting this up wrong?

 

 

 

Hi Fweeee,

It's not neccessary "wrong", but it's probably not a good idea to set the DataFilter on the Editor property of the column. The problem with this is that the grid will share the same editor amongst all columns that use the same type of editor. It does this for efficiency. So what you are doing here will actually not limit the DataFilter to only columns that have a Format of "c", because the same editor is probably being used for every column in the grid. 

The thing to do is to create a new editor of the appropriate type. Check the column's EditorResolved to see what the default editor type is. Create a new instance of that type. Assign the DataFilter to that editor, then assign that editor to the columns you want to have the DataFilter applied to. 

Whether or not that has anything to do with the performance issue, I don't know. I kinda doubt it. But try it out and if that does not help with the performance, we'll need to explore some other options. Maybe you can create a sample that demonstrates the slow scrolling and submit it to Developer Support so they can take a look. 

 

 Mike,

 Thanks for your help – I've sorted out all of my (current) issues with this.

I did as you suggested (Setting an Editor to the column), but this did not resolve the issue.

After spending some time constructing a small application demonstrating the issue, I realised that the problem was with Console.Writeline. I was using this in the DataFilter code to help me sort out issues, and had not removed it yet. I didnt think this would  be significant, but by my calculations, each call to Console.Writeline was adding about 0.09 seconds of overhead (well, slowing it down by 0.09 seconds). This quickly adds up while scrolling thorugh hundreds of records.

Thanks for your help.

That makes sense. I've done the same thing. I find that if the Output window in VS is not actually visible, it's much faster. But if it is visible and on the screen, it can slow things down quite a bit.