Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Forum,
Here is a problem. Client has users in multiple countries who are using the same QVS-based application. Date format is different from country to country, for example DD/MM/YY in Europe, and MM/DD/YY in US. They want to be able to see the data in their respective format.
Is there a reliable way to implement this? Appreciate any ideas, especially the crazy once - they help to think.
(I've implemented a clumsy solution based on time functions that worked OK in QVS 8.01, but behaves rather erratic in QVS 8.50. I reported a bug to QlikTech.)
oh! man. I was just wondering what I would suggest next if you say "nope, didn't work". 🙂 Glad it worked.
Thanks for your confirmation.
I think this thread deserve to be a Wiki.
Done, it is on Wiki now, thanks
Michael,
Nice solution. The only downside I see is that the macro requires system access. Would it work to do it this way, which does not require system access?
sub DateFormat
df = ActiveDocument.Evaluate("getregistrystring('HKEY_CURRENT_USER\Control Panel\International', 'sShortDate')")
df = UCase(df)
ActiveDocument.Variables("vDF").SetContent df, true
end sub
-Rob
Rob,
If you look up the thread you'll find almost exactly this...
The problem is that it gets the registry info from server, not from user.
Client will have to leave with the system access if they really want the feature.
BTW, I've noticed earlier that the QV now() function returns server time instead of user on the server-based apps (if they are different), but VBscript "now" always takes it from user. I had to use this:
private sub vNow
n = CDbl(now)
ActiveDocument.Variables("vNow").SetContent n, true
end sub
Michael Solomovich wrote:If you look up the thread you'll find almost exactly this
Michael,
No, I believe I am suggesting something different. Rakesh suggested using the QV GetRegistryString() function in a variable expression.
I'm suggesting using the QV GetRegistryString() function in the OnOpen macro VBSCript. You should then be executing in the user's machine -- just like your other example. Except without System Access required.
-Rob
That's correct Rob, Rakesh suggested it in the variable definition, but I actually tried it by OnOpen event exactly because of the same reason you're thinking of. Moreover, I even tried to attach it to a button to be able to run it directly in the application on any box, user or server - and it returned server info in any situation.
I'll be happy if you prove me wrong in this case...
Ok, I'm guilty of incomplete reading. I see you had already tested and reported the failure of exactly what I suggested. I can't make it work either.
-Rob
Thanks for testing...
Hi Michael,
Can you confirm that this method actually returns the users local settings, as my attempts seems to return the servers regional settings?
Or perhaps you solved the quest in another way?
Thanks!