Uniface User Forum

So, we recently 'solved' some display issues for the web (date formats) by applying the $nlslocale based on the locale of the client browser. 

Unfortunately, this has re-introduced the issue which has prevented us from using $nlslocale since it's inception. Namely, when one uses a structure such as :-

activate servicename.operationname("ID=%%vNumeric%%%", vOutparams)
or
vInparams="ID=%%vNumeric%%%"

Which are rife through our system (parameters as strings to get past the old urr update issues), then pNumeric is passed formatted (with a thousands separator), and therefore any number over 999 is not passed to the service correctly. 

I know I can 'fix' this by doing :-

vInparams = ""
putitem/id vInparams,"ID",vNumeric
activate servicename.operationname(vInparams,vOutparams)

or by using $concat or similar within the activate, but the problem is endemic to the system, and changing them all is not going to be easy or foolproof. 

I was wondering, if I set the $nlslocale in the postActivate, rather than in the preActivate, would uniface fields still get formatted correctly? 

Is there some other way of having it not apply to %% substitution and only to field display formats? 

I'm going to try the postActivate and see what happens, wish me luck. 

Iain

So that is so close. Static text fields are displayed as per the locale, but input fields are displayed and input as per the 'classic', so I can't use this as a workaround. 

Anyone got any ideas short of manually going through all dsps and services and changing the way we pass parameters. 

Hi Iain

"short of manually going through" => so the solution ist:Let UnifAce do the job 🙂

Is the pattern always?

("ID=%%vNumeric%%%",

The you can create a little programm which loops over all proc-containers which:
looks out for all "activate" on first place in a line
Checks, if the pattern matches
replace the call by

$66 = "" ;  *)
putitem/id $66,"ID",vNumeric
($66,

*) $66 is a global register which I hope is not elsewhere used
One can also use a (new) global variable
Or a component local variable but the you have to update "UXREGS" (UF9) or the proccontainer (UF10)
Or a proceure local variable, but then you have to search for the begin of the procedure/operation/trigger and add a variable. possible but much mor complex

I did such replace some times 🙂
E.G. replace by "run <component>" by "call GP_RUN(<component>,"")"

Ingo

Ah if only, that was a sample of where the problem occurs.  

Sometimes the inparams might be 

"NAME=%%vString%%%;VALUE=%%vNumeric%%%"

Sometimes the code might be

vInparams="ID=%%vNumeric%%%"
putitem/id vInparams,"VALUE", vValue

All of these formats now fail me because uniface now includes commas in the passed value. 

I'd be very reluctant to pass a parser over all 700 of my dsps and services to try and identify places where %% is being used for intercomponent communication, and where it is being used to format (for example) messages to the user. 

Since our CS app is n-tier, I fortunately don't have to do all of them, because the services are (mainly) run on a different userver, where nslocale is not set, but problems keep cropping up. 

It's made worse by the fact that it doesn't fail on small datasets (like development data sets) where the ID tends to be < 999 🙂 

Hi Iain

Then you do have the same problems then I face sometimes
Our code is partly still Uniface 7 compatible 🙂
And colleagues tend to write parameter like yours, without "putitem"

Ingo