I have two problems regarding the formatting of my table:
All of my Dimensions are completely uppercase. If I launch the query in the MDX IDE, I get results as expected, but in the reportingtool (/icCube/doc/ic3report) everything is uppercase. Unfortunately I couldn't find any setting to change that yet.
I would like to display my number formatted in the german style (, as decimal sign and . as thousands separator). If I put in my query FORMAT_STRING = '0.000,#' of yourse the system doesn't know, what is meant. Is there a way to tell, how I would like to see the numbers?
Thanks for your help
~Ulrich~
Can you be more precise about the 'faulty' widgets and what is badly displayed (dimension name, member name, etc). The Web reporting should not change the case of the model definition.
The thousand separator used is defined by the locale not by the FORMAT_STRING definition. You should define the locale of the user as German. Note, if no locale has been defined then the icCube server (i.e., Java process) locale is used.
Note: in the FORMAT_STRING definition, the '.' represents the decimal separator and the ',' the thousands separator. I believe your example should be: '0,000.#'. More details can be found here.
Hope that helps.
After a restart of the IcCube Server the right locale is now recognized and this part is working.
As for the words all in capitals I found out, that this happens, if no style is chosen in the widgets/filters. Once I chose a style, I had everything written as it should.
Related
I would like to determine the Thousand Separator used while running a VBA Code on a target machine without resolving to calling system built-in functions such as (Separator = Application.ThousandsSeparator).
I am using the following simple code using 'Format':
ThousandSeparator = Mid(Format(1000, "#,#"), 2, 1)
The above seems to work fine, and would like to confirm if this is a safe method of doing it without resorting to system calls.
I would expect the result to be a single char string in the form of , or . or ' or a Space as applicable to the locale on the machine.
Please note that I want to only use a language statement such as Format or similar (no sys calls). Also this relates to Thousands Separator not Decimal Separator. This article Using VBA to detect which decimal sign the computer is using does not help or answer my question. Thanks
Thanks in advance.
The strict answer to whether it is safe to use Format to get the thousands separator is No.
E.g. on Windows, it is possible to enter up to three characters into the Thousands Separator field in the regional settings in the control panel.
Suppose you enter asd and click OK.
If you now call Format(1000, "#,#") it will give you 1a000. That is only the first letter of your thousands separator. You have failed to retrieve it correctly.
Reading the registry:
? CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sThousand")
you get back asd in full.
To be fair, the Excel international properties do not seem to be of much help either. Application.International(xlThousandsSeparator) in this situation will return the separator originally defined in your computer's locale, not the value you've overridden it to.
Having that said, the practical answer is Yes, because it would appear (and if you happen to know for sure, please post an answer here) that there is no culture with multi-char thousand separator (even in China where scary things like 1ε2345δΈ6789 or 1ε2345θ¬6789 exist, they happen to be represented with just one UTF-16 character), and you probably are happy to ignore the people who decided to play with their locale settings in that fashion.
I have a table in which there is a column of type long.
In this column, we have stored the email responses. Now the problem which i am facing while querying business component which is on this table, is that the character ' is automatically getting converted to '
As shown in example below:
Value in column:
We've noticed some unusual usage on your phone.
Value coming while querying the Business Component:
We've noticed some unusual usage on your phone.
Although if i query in database directly, i am able to see ' correctly.
Can anyone suggest how this is happening ?
Thanks
The above link is related to Siebel.
So i will place my answer w.r.t Siebel. There is templates for communicating users in CRM.
Now if you do not mark HTML Template, then it will not convert the content of the body in UTF-8 format.
Since the HTML Type was unmarked in your case, speical character was not getting converted.
Mark it and your problem will be solved.
The template from which this field was picking up the value, we not in HTML Template format. For handling special characters like ', this property need to be marked.
Detailed info here : ExternalLink
I am working on a ASP.NET MVC app.
This app displays a detail information regarding a product.
The product name can have any special chars like single quote, the percentage symbol, the Registered symbol the one with a circle and 'R' inside, the Trademark symbol etc.
Currently all these are replaced with a '-'.
If the name is like this:
Super - Men's 100% Polyester Knit Shirts
It appears like this in the URL:
8080/super---men-s-100-polyester-knit-shirts/maverick
- men-s-100-polyester-knit-shirts
This is done in Js like so:
Name.replace(/([~!##$%^&*()_+=`{}\[\]\|\\:;'"<>,.\/? ])+/g, '-').replace(/^(-)+|(-)+$/g, '');
So the question is, should the name be displayed as-is in the URL?
If yes, some pointers please.
If no, please provide some valid reasons like standards as followed today that will help me put the point across the table.
Regards.
The short answer is not to fiddle with it. It's as good as it gets out of the box.
The Url can only contain a small number of alphanumeric letters. which basically means you can only have 0-9 a-z and - _ . ~.
All other characters need to be encoded. Now that you can have arabic url's too it has gotten a little more complicated.
But assuming your website is indo-european this is it. So you will never be able to have full product names in your url.
And renaming them as something more cool like replacing % with "percent" in the url can bring desaster upon your url's as in some cases the "fake" names may not end up unique and therefore end up with unreliable routing.
look at URI characters on wiki
I've looked into NSFormatter, NSNumberFormatter, and the other formatting classes, but can't find a build into solution. I need to format phone numbers depending on the country code.
For instance, for US, I get a string such as +16313938888 which I need to format to look like +1(631)393-8888. The problem is I need to do this for all formats. Netherlands, I receive a string +31641234567 which will be +31(6)41 23 45 67 (something like that).
Hardcoding for 200+ countries is too tedious and I really don't know all the format rules. Is there something in the docs I'm overlooking or does anyone know of an open source class that manages this?
See https://github.com/rmaddy/RMPhoneFormat for an iOS specific solution.
Try this Google solution - https://github.com/me2day/libPhoneNumber-iOS
They have ports for C++, Java, Objective-C and others.
Unfortunately iOS does not have any public APIs for this. You can try to integrate libphonenumber that is a complete implementation for parsing and formatting international phone numbers. It has a C++ version so theoretically you can cross-link with it.
You definitely don't want to hard-code all of the various country formats. There are typically 3-5 formats per country. Instead, use a format database (such as a plist) and write code to format the number based on the given country code.
A good international format property list 'UIPhoneFormats.plist' can be found here: https://code.google.com/p/iphone-patch/source/browse/trunk/bgfix/UIKit.framework/PhoneFormats/UIPhoneFormats.plist?r=7
In that list, '$' allows any character, '#' must be a number, and the '(space) ', '(', ')' and '-' are inserted between numbers. Non-numeric characters typed by the user hint to the desired format.
I've shared my phone number formatter class, inspired by Ahmed Abdelkader's work, at https://github.com/lathamglobal/iOS-Phone-Number-Formatter . It is a very small, single-class international phone number formatter that uses the plist just mentioned.
You can try this:
let phoneNumber : CNPhoneNumber
let digits = phoneNumber.performSelector("digits").takeRetainedValue() as! String
It gives you directly the string, without formatting, with the phone number. However if the number is saved with international prefix, you will have it also in the resulted string.
I have an instance of NSTextField, e.g. someTextField, for which I will use the number formatter to limit the input to numbers only.
The problem comes with the localization combined with the specific keyboard layouts used.
I would like to allow both the, say, American and European users to enter their localized decimal separators. As you all know, in the USA that would be . and for the good part of Europe that would be , (and similar with the thousands separator, etc. but let's put that to the side for now).
So I wrote the following task:
[numberFormatter setLocale:[NSLocale currentLocale]]; for the instance of the NSNumberFormatter.
Problems occurs when the user who has , set as a decimal separator AND US keyboard layout switched on (fairly common here in Europe) presses the decimal separator key on the numeric keyboard. With the US keyboard layout on, that would give him the . as the decimal separator but at the same time it'll be ignored in the someTextField because of the localized settings system-wide. So, if you want to type 1/2 using numeric keyboard only, you'll type 0.5 (US keyboard layout) in the text field and it would be read by the system as 0 because it recognizes only , as decimal separator. This is how the program currently is working and I would like to improve it in this regard.
I would like to allow user to type in the . in the someTextField and for the system to recognize it as a decimal separator just like it would ,. This kind of behavior can be seen in Apple's own Calculator application. If you type . on the numeric keyboard it'll appear as , immediately on the screen (for all conditions as described previously).
Question is: is it possible for me to achieve this using an instance of NSNumberFormatter? If not, is it possible to set on-the-fly conversion of the numerical keyboard decimal separator key output to the decimal separator set system-wide? Or perhaps you have some other suggestions?
Thanks.
I don't have a specific answer to your question, but I'd say the right approach is not to muck about with the NSNumberFormatter at all and concentrate on trying to change the characters generated by the keyboard.
The default locale for number formatters is usually the system's default locale as set by the user in the internationalization settings. If you change that behaviour programmatically for UI elements, you are effectively telling the user "I know better than you how you want to input numbers". Arrogance of that sort on the part of the developer never gets them good marks with respect to UI design.
In fact, you could apply the same argument to remapping the dot button on the numeric keypad. How do you know that the user hasn't set US keyboard layout because it allows them to get a dot from that key? Maybe they consider it more important to be able to type the thousands separator from the keypad than the decimal separator. I'm not saying you shouldn't implement your feature, just make sure that the user has control over when it is enabled or disabled.
Anyway, you probably want to override the keyDown event on the control. More info here.
Take a look at the UITextFieldDelegate protocol. It allows your textfield to ask its delegate if it should accept a character which the user just typed. The apropriate method would be textField:shouldChangeCharactersInRange:replacementString. If the character in question is , or . just let the delegate append the properly localized decimal separator "manually" and return NO.
I'm not quite sure if this will work if the text field is set to number mode, maybe the input is being filtered before the delegate method is called - leading to the method not being called if the "wrong" separator has been filtered out previously. If so, you might want to consider leaving the text field in alphanumerical mode and use the delegate method again to filter out anything that is not numbers or separators. However, in this case you should make sure the user is not allowed to type more then one decimal separator - either ignore the surplus ones or remove the first one and accept the new one.