Start Building Professional
Web Apps Today

Documentation errors and link not clickable after addRow

Hello!

Thank you for a fantastic product (dhtmlXgrid). I have been playing around with it for a couple of days and most things work fine. I have a minor complaint in general though. Please, when you make a typo in the documentation or this knowledge base, please correct it after you are informed about it. So we don't have to repeat the same mistakes over and over again.
One is setNumberFormat, where the parameters are not correct at a number of places in your documentation. Please also specify what parameters can be empty or not. This took me five hours to figure out! Thanks.

Now, my problem:
I have a grid with a link image, defined in XML - this works fine for existing rows.
But, after adding a row the link image on the new row is not clickable, it feels disabled. The old rows still work fine. Everything else on the new row seems to work fine, except the link.

mygrid.addRow(234, "Text1,<![CDATA[<a href='#' onClick='lMyClick(2);'><img class='grid_img' src='images/button.gif'></a>]]>", 2)

Please help, thank you.
/Hans

>>One is setNumberFormat, where the parameters are not correct at a number of places in your documentation.
Sorry for inconvenience, we tries to have documentation up to date, but probably there are few outdated articles
In case of setNumberFormat the documentation states correct order of parameters

>>I have a grid with a link image, defined in XML - this works fine for existing rows.
You need not to use CDATA sections when adding rows by javascript ( CDATA is native XML construct, which has sense only inside XML )
So the correct code will be
    mygrid.addRow(234, "Text1,<a href='#' onClick='lMyClick(2);'><img class='grid_img' src='images/button.gif'></a>", 2)

1. >> documentation states correct order of parameters
I am sorry, but I think you are wrong.

I thought it was a bug, untill I tried switching the two delimiter parameters, voilá it works!
I think you would want to change the docs.

gc_k = ".";
gc_digit = ",";
mygrid.setNumberFormat("0,000.00", 4, gc_digit, gc_k);

25000.50 then displays correctly as 25.000,50 - German, Dutch, etc. number format.

2. BUG?
There is also a bug (or lack of documentation) in that both delimiters must have a value, ie, cannot be empty.
gc_k = "";
gc_digit = ",";
mygrid.setNumberFormat("0,000.00", 4, gc_digit, gc_k);

25000.50 then displays wrongly as 25,000,50 - Alien number format ;-)

3. SUGGESTION:
Make a couple of global variables which can be assigned by a function call (I saw you have one for "default delimiter"):
My wish list for global variables:
mygrid.setKDelimiter(",")
mygrid.setDigitDelimiter(".")
mygrid.setDateDelimiter("/")
mygrid.setTimeDelimiter(":")

With that you can solve the inner cell formatting hack (on the two places I found in your KB):
this.edit = function(){this.cell.atag=((!this.grid.multiLine)&&(_isKHTML||_isMacOS||_isFF))?"INPUT":"TEXTAREA";this.val = this.getValue();if(typeof(dhtmlX_d_delimiter) != "undefined"){this.val=this.val.toString().replace(".",dhtmlX_d_delimiter);};

That would be excellent!
Sidenote: This is something almost all programmers overlook when writing components.
But at least you have made half the work already, which is more than can be said for our provincial collegues in the U.S. ;-)

>>You need not to use CDATA sections when adding rows by javascript
Thank you now links in new rows works fine!

>>mygrid.setKDelimiter(",")
>>mygrid.setDigitDelimiter(".")
>>mygrid.setDateDelimiter("/")
    The setDateFormat and setNumberFormat , basically covers the usage of above statements

>>mygrid.setTimeDelimiter(":")
   This one seems as a good addition for "time" excell, which uses hardcoded separator for now. We will add something similar in next version of the grid.


>>There is also a bug (or lack of documentation) in that both delimiters must have a value, ie, cannot be empty.
This was an unexpected usecase, the code of grid treats empty string as not defined separator and uses default one.
We will fix it in next build of dhtlmxgrid.

>>I think you would want to change the docs.
I agree that documentation describes it very briefly and need to be extended
The default setNumberFormat works correctly for locals which use dot as decimal separator ( so basically it is correct in its existing state )
If you want use comma as separator - the parameters need to reversed ( but still documentation is correct, the third parameter are group separator, the 4th parameter are decimal separator )

Hi again,

Lets not turn this into a long thread. I just want you to support different number formats. That's it.
All my applications needs to support many native number and date formats.
When calculating in JavaSCript from what I know the browser resorts to no group delimiters and dot as decimal separator for any math operations.
And you handle this greatly in your application! All that is well.
I just want more people to find out that your international number formatting actually works, if you don't follow the docs! I am just trying to help.
Belive me, this is a great obstacle from using JavaScript components for calculations, since they scale poorly across borders.
Here are some number formats which would be nice to have examples for:

Whole numbers:
1,234 (US English)
1234 (English)
1 234 (French + Greek + Swedish)
1.234 (Danish + Russian)
1'234 (Swiss)

Currency values (sometimes different to the above in the same country):
1,234.56 (US English)
1234.56 (English)
1 234,56 (French + Swedish)
1.234,56 (Danish)
1 234.56 (Greek)
1.234 56 (Russian)
1'234.56 (Swiss)

>>If you want use comma as separator - the parameters need to reversed ( but still documentation is correct, the third parameter are group separator, the 4th parameter are decimal separator )

That doesn't make sense.
If I want French currency format I can do that by:
mygrid.setNumberFormat("0,000.00", 4, ",", " ");
The "mask" property is US English currency format. Nothing is "reversed", 3rd parameter is decimal separator, 4rd parameter is digit separator, which is NOT what the documentation say.
Unless all of this has something to do with the format of the "mask" property?

>>The setDateFormat and setNumberFormat , basically covers the usage of above statements
You are right, it's just that it is much easier to handle settings on applicaton level if each setting is separate. It would be nice to have control over formatting for each column, one setting for each delimiter, round, math-columns, etc. 
Call me lazy or call me picky. Today I need to format some of the numbers myself. Which slows things down.

Have a nice evening!
/Hans