 |
|
|
Thank you for a very nice code but I found a small bug in the JS file.
type = float
In function Check(Type, DecimalSeparator)
.............
if(KeyAscii == "-")
{
if(Obj.value != "")
{
event.returnValue = false;
return;
}
return;
}
The problem is :If you type "123",you can't type "-" before "123" to represent the value -123.
(Althought it is valid)
Could you please help me to solve this bug!
|
|
|
|
|
|
|
The Numeric input javascript seems to give me errors in Firefox. Has anyone had this? The error its giving me is :
"event is not defined" on line 55 which is the line :
var Obj = event.srcElement;
in the Check function
|
|
|
|
|
|
|
This control was never tested n FireFox.
If you have a fix then please send it to me and I will update the article.
|
|
|
|
|
|
|
First great JS!
I have been puting this in production, and one my user requested that when the input text is selected for instance 0.00 slected, it should be possible to type in directly a new decimal value.
This is not possible with the current code.
I changed your code to fit my needs and thought I would share here:
in the check function, Imade the following changes:
if(KeyAscii == DecimalSeparator)
{
//--------------------------------------------------------------------
//to allow entering directly a . if the selected text has a dot selected
var selectedText = "";
selectedText = (document.all) ? document.selection.createRange().text : document.getSelection();
//alert(selectedText);
var DotPos2 = selectedText.indexOf(DecimalSeparator);
if( DotPos >= 0)
{
if(DotPos2 >= 0)
{
}
else
{
event.returnValue = false;
return;
}
}
//if( DotPos >= 0)
//{
//event.returnValue = false;
//return;
//}
//--------------------------------------------------------------------
return;
}
Now the functionnality is available.
Regards,
Antoine
_________________
Always trying my best
|
|
|
|
|
|
|
Please, the DLL is not there
aferrando@jerarquicossalud.com.ar
Thanks !
Antonino Ferrando
|
|
|
|
|
|
|
Hi. There is no dll in the Zip Folder..
Please upload it..
Thanks
Ratul Saikia
|
|
|
|
|
|
|
The only files that are included are as follows:
NumericInput_src
--Properties
----AssemblyInfo.cs
--Resources
----NumericInput.js
NumericInput.cs
NumericInput.csproj
Unfortunately, the folder does not include the .dll file. Am I missing something here?
Tony Morris
morris.osu@gmail.com
-- modified at 18:53 Tuesday 7th March, 2006
|
|
|
|
|
|
|
I have sent an updated zip file to codeproject and copied you on it
|
|
|
|
|
|
|
|
|
|
Can you send me the DLL File ?
aferrando@jerarquicossalud.com.ar
Thank you!
Antonino Ferrando
|
|
|
|
|
|
|
the DLL file is not there???
can you update the zip file so that it contains the DLL file
Sajid Saeed
|
|
|
|
|
|
|
No he podido hacer integrar el DLL a la barra de herramientas. Me marca que no es un elemento de .NET Auxilio que puedo hacer.
|
|
|
|
|
|
|
I do not know what language you are speaking.
Please correspond in english.
|
|
|
|
|
|
|
Sorry. I can't install the DLL at toolbox. When i try to add it i recive this error: NumericInput.dll is not a Microsoft .NET module.
Thanks.
|
|
|
|
|
|
|
I just added it myself with no problem.
Are you sure you are using ASP.NET 2.0?
It only works with 2.0
|
|
|
|
|
|
|
It is spanish and my high school spanish skills are too rusty 
PJC
|
|
|
|
|
|
|
Never mind, saw the translated post :->
|
|
|
|
|
|
|
This control has no internation support. The decimal separator is hardcoded into the client script.
Rather then loading the script form the resource try registering it programmatically: in this way you will be able to modify it on the fly using the current UI colture and replacing the hardcoded dot with the appropriate decimal separator (i.e.: comma).
|
|
|
|
|
|
|
Help me out here a bit.
If you have a normal web form with a currency value text box and you enter "123,45", do you yourself have to change the "," into a "." on the server-side before inserting into the database?
It is not a problem to expose a new property "Decimal separator", but before I do, I need to know what the ramifications are.
|
|
|
|
|
|
|
Do not expose a property "Decimal Separetor": that actually leads to more errors. You need to do this automatically.
In the file NumericInput.js you have hardcoded the decimal separator as "." (dot).
You should replace that hardcoded character in the script with something different depending on the user colture.
The idea here is that you don't replace the "," into "." while the user type the text: you simply replace it once before rendering the client script in the page.
This is what you need to do:
1) read the current UI culture settings using these:
Thread.CurrentThread.CurrentUICulture.NumberFormat.CurrencyDecimalSeparator
Thread.CurrentThread.CurrentUICulture.NumberFormat.NumberDecimalSeparator
2) Build up the script text using the information of point (1). Use a string builder to improove performance.
StringBuilder sb = new StringBuilder();
sb.AppendLine("<script type=\"text/javascript\">");
sb.AppendLine("function NumericInputKillExtraDigits(Val, Type)");
sb.AppendLine("{");
.....
.....
use the information from point (1) to build the script
.....
.....
sb.AppendLine("}");
sb.AppendLine("</script>");
3)Register the script text on the fly using something like this
Page.ClientScript.RegisterClientScriptBlock(typeof(PNumericInput), "PNumericInputScriptBlock", sb.ToString());
Hope this helps.
- Simone
|
|
|
|
|
|
|
Unfortunately, this approach renders in the culture of the SERVER, not necessarily the USER. So, the user enters a number into the control formatted the way his specific culture allows, and the control (possibly) blows up or renders an incorrect value because the server is not culturally "with" the user.
Possibly the only way around this kind of issue is either to code it exactly they way Gary did and alert the user with descriptive text telling them how the number SHOULD be entered, or to extend the control as previously selected to allow a culturally different separator and override the default when you can definitively identify the user's culture.
I have never used the word "culture" or any derivation thereof more than I did in the last 2 paragraphs....
"When everyone is out to get you, paranoid is just good thinking" - Dr. Johnny Fever
|
|
|
|
|
|
|
Hello Dave,
I don't agree with you. The control is correctly coded. The control must run with the same UI culture of the current thread on the server or the page will be messed up with a mix and match of controls using different UI cultures. All the standard dotNet controls from Microsoft and any other third party vendor will use the UI culture of the current thread.
I guess the part that you don't see here is that the container Page has the duty to switch the UI culture of the current thread to match the current culture of the client machine. This can be done by reading the language cookie from the browser. Or you can even give the option to the user to choose a "preferred language" that override the browser language. In few words the control is correctly coded in this way. The logic for the UI culture switch remains outside the controls.
|
|
|
|
|
|
|
I'm sorry, I guess I didn't state it very clearly at all. I agree with you that the control is written right in so far as it should be aware of the current thread's culture and adapt accordingly (which was the point I messed up on the previous post). I am a proponent of intelligent controls. Anything emitted by the control should be consistent with the culture under which the control is instantiated.
As far as the technique of switching the current thread to match the culture of client - well, I am very familiar with threading issues, but did not know about the language cookie until your post. In my past experience, this has been set on a global level at the server and not on a client by client basis. Learn something new no matter how hard you try to avoid it  . I don't have as much call for globalization of an application because 90% of my clients have me working on internal apps. But point noted, and thanks for the info.
On re-reading this, I think I should say that ultimately it all depends on the intended use of the control. If developed/used for purely internal applications where the culture is determined by the IT staff, then it is perfectly acceptable to hard code the separator. Otherwise, as a web control it should be intelligent enough to adapt to the culture of the environment. This assumes, of course, that the container developer has done something such as you have suggested.
"When everyone is out to get you, paranoid is just good thinking" - Dr. Johnny Fever
-- modified at 10:06 Wednesday 8th March, 2006
|
|
|
|
|
|
|
Hello Dave,
Internazionalization is a really hot topic nowadays. I'm not an expert by all means, but I think it is worth to clarify a bit more for the other readers that are interested in building internation-aware controls:
IIS has a thread pool that is used to serve client requests. Each client request get assigned a thread from the pool. The code above is setting the culture for the particular thread assigned to the current request. It does not change the culture of the server, and it does not change the culture for any other consecutive request from other clients.
By default ASP 2.0 detect the culture of the web browser using the browser cookie and sets the current UI culture for the thread. This means that if your control reads the current thread culture then there is no extra work to be done from the developer: it will work out of the box.
Now there are some cases in which the auto-detection migth not be convenient for the user (e.g. a Spanish-speaking user using a computer in a Chinese Internet Cafe'). In that case you could override the current UI culture based on a used preference. In example your web application migth be detecting the current UI culture by default but it migth also have a drop down somewhere in an option page that allows the user to "switch" the page language on the fly. This actually allows for some very cool stuff if combined with the new resource support in ASP 2.0
When you work on an application for "internal use" it is probably ok to use the hardcoded language, but it only takes two extra lines of code to set the correct culture, and IT depertment can "change their mind" on what language they want to support at any point in time, so you are better off adding those extra lines.
On the other end if you intend to seel your controls then the internationl support opens the door to a huge international market.
On a side note I believe that in USA it is mandatory to provide foreign language support for all user interface in any work plave in which more then X percent of the work force speak english as second language (ESL) (this is very common on the factory floor). I believe that it is also mandatory for all government-related application to support the language used form their local minority. Again this requirement migth not be enforced in all cases, but it is a good selling point when you bid on a project.
Doing it rigth the first time will save you from having to fix the code later: it is always easier to add the internation support from the beginning then forcing it later, and once you start thinking "international" then it will come natural to you.
ASP 2.0 also offer a convenient way to test internation feature by overriding the language of the ASPX page trough the property "Culture" of the Page object which by default is set to "auto".
You can find more information on internationalization in ASP 2.0 at the following link:
http://www.asp.net/QuickStart/aspnet/doc/localization/localization.aspx
-- modified at 11:16 Wednesday 8th March, 2006
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin