My application is currently displaying negative numbers as -1. The users have changed the requirements (just for a change!) and now we will have to display the numbers as (1).
Can I enable that for the whole application say changing the web.config or even the app's CultureInfo ? Is there any side effect of doing that since we have lots of pages that contain number validators ?
Thanks !
For currency it is really easy:
String.Format("{0:C}", value)
This will use the culture info for the system.
For normal numbers being data bound, use Mark Glorie's sample.
MSDN Article
I'd use String formatting. Making a change to the application's configuration to satisfy a UI requirement is heavy-handed. SteveX wrote a great blog post about String formatting. It's also compatible with markup (aspx) instead of only relevant in code.
From his post:
String.Format(”{0:$#,##0.00;($#,##0.00);Zero}”, value);
This will output “$1,240.00″ if passed 1243.50. It will output the
same format but in parentheses if the number is negative, and will
output the string “Zero” if the number is zero.
Which isn't exactly what you want, but it's close.
Check this..
http://msdn.microsoft.com/en-us/library/91fwbcsb.aspx
Converts the string representation of a number in a specified style to its Decimal equivalent.
I've got the following page bookmarked for doing string formatting: http://idunno.org/archive/2004/14/01/122.aspx
About halfway down, it gives the answer:
String.Format("{0:£#,##0.00;(£#,##0.00);Nothing}", value);
To answer your other question, I wouldn't modify the app.config to make it global, for reasons given in the other answers.
String.Format(”{0:f;(f);0”, -1);
This works.
DataFormatString="{0:c0}"
Nagative amounts in paranthesis
Thousand separater - comma
$ symbol in front
You could always write your own custom ToString() method as an extension method, but like you mention, using CultureInfo is probably better. Take a look here:
http://msdn.microsoft.com/en-us/library/system.globalization.numberformatinfo.numbernegativepattern.aspx
Are you displaying your data in Gridview/Datagrids? If so then formatting can be applied per bound-column, something like:
<asp:BoundField DataFormatString="{##;(##)}"/>
This only works with integers however...
Related
TYPO3 8.7.x, Powermail 6.0.0
I'd like to override the receiver based on two subjects they can select.
Now I know that this works just fine:
[globalString = GP:tx_powermail_pi1|field|konsilbereich = 5]
But this does not seem to work:
[globalString = GP:tx_powermail_pi1|field|konsilbereich = "Some phrase"]
I read that some workarounds were to have a hidden field that's been filled by Javascript upon a users selection and instead of the actual field, the hidden field gets submitted. But that is not an option for us.
I checked the docs as well as many support forums but could not find a good answer to this.
Is this not possible, or if, how would I accomplish that I can use an actual string within the comparison?
The problem is a comparisation with a string in TypoScript conditions. Strings could have space, special characters or umlauts. That's why TypoScript works best with integers.
Two possibilities come into my mind for your case:
1) Building an own conditition is quite simple in TYPO3 (see https://docs.typo3.org/typo3cms/TyposcriptReference/latest/Conditions/Reference.html#custom-conditions for an easy example)
2) Use an integer together with GP: - but then I would use a selectbox with a text as label and a number as value
I'm working on a Spring MVC Project and ran into a problem with the internationalization in forms, especially the number formatting.
I already use fmt:formatNumber to format the numbers according to the current selected locale.
<fmt:formatNumber value="${object[field]}"/>
Like this, number formatting works well when I display numbers. But how about the forms?
At the moment, the input fields that are supposed to receive float values are prefilled with 0.0 and expect me to use "." as decimal separator, no matter what locale is selected. Values containing "," are refused by the server (...can not convert String to required type float...).
How can I make my input fields use and accept the appropriate number format as well?
Did you have a look at #NumberFormat? If you annotate the property the input field is bound to, this should result in the proper formatting. Something like:
#NumberFormat(style = Style.NUMBER)
private BigDecimal something;
This style is the "general-purpose number format for the current locale". I guess, the current locale is determined threadwise from the LocaleContextHolder.
Your app needs to be annotation-driven, also see the section "Annotation-driven Formatting" in the docs.
You might want to take a look at the DecimalFormatSymbols as suggested in this answer.
I'm doing some client-side stuff with Javascript/JQuery with .Net controls which expose their GUID/UniqueIdentifier IDs on the front end to allow them to be manipulated. During debugging something is driving me crazy: The GUIDs in the db are stored in uppercase, however by the time they make it to the front end they're in lowercase.
This means I can't quickly copy and paste IDs into the browser's console to execute JS on the fly when devving/debugging. I have found a just-about-workable way of doing this but I was wondering if anyone knew why this behaviour is the case and whether there is any way of forcing GUIDs to stay uppercase.
According to MSDN docs the Guid.ToString() method will produce lowercase string.
As to why it does that - apparently RFC 4122 states it should be this way.
The hexadecimal values "a" through "f" are output as lower case characters and are case insensitive on input.
Also check this question on SO - net-guid-uppercase-string-format.
So the best thing you can do is to call ToUpper() on your GUID strings, and add extension method as showed in the other answer.
If you're using an Eval template, then I'd see if you can do this via an Extension method.
something like
public static string ToUpperString(this Guid guid, string format = "")
{
string output = guid.ToString(format);
return output.ToUpper();
}
And then in your Eval block,
myGuid.ToUpperString("B")
Or however you need it to look.
I'm on my Mac at the moment so I can't test that, but it should work if you've got the right .Net version.
Looks like a simple task - get a regex that tests a string for particular length:
^.{1,500}$
But if a string has "\r\n" than the above match always fails!
How should the correct regex look like to accept new line characters as part of the string?
I have a <asp:TextBox TextMode="Multiline"> and use a RegularExpressionValidator to check the length of what user types in.
Thank you,
Andrey
You could use the RegexOptions.Singleline option when validating input. This treats the input as a single line statement, and parses it as such.
Otherwise you could give the following expression a try:
^(.|\s){1,500}$
This should work in multiline inputs.
Can you strip the line breaks before checking the length of the string? That'd be easy to do when validating server-side. (In .net you could use a custom validator for that)
From a UX perspective, though, I'd implement a client-side 'character counter' as well. There's plenty to be found. jQuery has a few options. Then you can implement the custom validator to only run server-side, and then use the character counter as your client-side validation. Much nicer for the user to see how many characters they have left WHILE they are typing.
The inability to set the RegexOptions is screwing you up here. Since this is in a RegularExpressionValidator, you could try setting the options in the regular expression itself.
I think this should work:
(?s)^.{1,500}$
The (?s) part turns on the Singleline option which will allow the dot to match every character including line feeds. For what it's worth, the article here also lists the other RegexOptions and the notation needed to set them as an inline statement.
I have a query string parameter value that contains an ampersand. For example, a valid value for the parameter may be:
a & b
When I generate the URL that contains the parameter, I'm using System.Web.HTTPUtility.UrlEncode() to make each element URL-friendly. It's (correctly) giving me a URL like:
http://example.com/foo?bar=a+%26b
The problem is that ASP.NET's Request object is interpreting the (encoded) ampersand as a Query String parameter delimiter, and is thus splitting my value into 2 parts (the first has "bar" as the parameter name; the second has a null name).
It appears that ASP.NET is URL-decoding the URL first and then using that when parsing the query string.
What's the best way to work around this?
UPDATE: The problem hinges on URLRewriter (a third-party plugin) and not ASP.NET itself. I've changed the title to reflect this, but I'll leave the rest of the question text as-is until I find out more about the problem.
man,
i am with you in the same boat, i have spent like hours and hours trying to figure out what is the problem, and as you said it is a bug in both, as normal links that contain weird characters or UTF-8 code characters are parsed fine by asp.net.
i think we have to switch to MVC.routing
Update: man you wont believe it, i have found the problem it is so strange, it is with IIS,
try to launch your page from visual studio Dev server and Unicode characters will be parsed just fine, but if you launch the page from IIS 7 it will give you the ???? characters.
hope some body will shade some light here
I would have thought that %26 and '&' mean exactly the same thing to the web server, so its the expected behavior. Urlencode is for encoding URLs, not encoding query strings.
... hang on ...
Try searching for abc&def in google, you'll get:
http://www.google.com.au/search?q=abc%26def
So your query string is correct, %26 is a literal ampersand. Hmm you're right, sounds like a bug. How do you go with an & instead of the %26 ?
Interesting reading:
http://www.stylusstudio.com/xsllist/200104/post11060.html
Switching to UrlRewritingNet.UrlRewrite did not help, as it apparently has the same bug. I'm thinking it might have something to do with ASP.NET after all.
I think URLRewriter has a problem with nameless parameters (null name).
I had a similar problem. When I gave my nameless parameter a (dummy) name, everything worked as expected.