Hello,

I'm new at UTF8 encoding.

My company uses an existing extended ASCII based system written in PxPlus. For the most part the system is still character based. The system is running on Linux and users logon using a terminal emulator. A smaler part of the system are Nomads panels running through WinDx. Our system does not have the 'U8' parameter set.

Up until now in the character based screens users have only been able to use the characters in the extended ASCII set. In the WinDx screens users can enter UTF8 characters, but all progams handle data as extended ASCII only. On a few occasions this results in unwanted results, but we have come to accept that. Now our users would like to be able to use a few more characters in a limited number of Nomads screens. We are not planning on UTF8 encoded data being used in character based screens. All in all I'm reading up on my UTF8.

On the internet I found articles explaining the US ASCII characters (ASCII 000 through to 127) remain the same in UTF8 however the extended ASCII characters and all other are encoded differently. From the PxPlus manual I understand when using UTF8 the 'U8' parameter should be set system wide. Switching the parameter on and off where needed will probably have unwanted results. This makes me wonder what the impact of switching this parameter on system wide will have on existing programs and data.

For a test I set the 'U8' paramater to include returning an error in case of incorrect UTF8 data (value 2). After that test I ran the *UPB utility (string search and replace), resulting in quite a few errors. Something similar happened when interpreting the value of a FID function.

As another test I ran this bit of code :
a$=$C38AC38A$
for b$ from a$
print b$
next b$
With the 'U8' parameter set I expected the program to interpret the value of a$ as UTF8 and use $C38A$ as the separator returning two empty lines. The porgram however used $8A$ as separator returning a repesentation of $C3$ twice. This tells me non US ASCII characters will no longer be suitable separators in strings where UTF8 characters might appear.

These examples got me a bit worried we might me missing something.
For example :
- do we need to convert all data in our database to UTF8 ?
- could input statements start returning extended ASCII characters encoded differently than before ?
- will existing programs struggle finding extended ASCII characters in strings if they by mistake turn out to contain UTF8 content ? (return the position of that character if it's part of an UTF8 character)

All thoughts are very welcome !

Cheers,
Arno de Greef

PxPlus has shared with us a fix that seems to have resolved the issue.

Thanks!

I see the same thing happen, however if I change the multi-line height to 2 (a multi-line multi-line  ), the problem seems to disappear.

Thank you PxPlus for your reply.

If I understand correctly, you suggest something like

In the initialization procedure : "CALL.PRG",my_object_ctl
In the closing procedure : "CLOSE.PRG",my_object_ctl

I tested this in the attached example. CALL.PRG puts 100 in the variable and CLOSE.PRG shows a messagebox with the received variable.

To test I used

%nomads'QueryProgram$="*winqry"
process "test","demo.en"
%nomads'QueryProgram$="*winqry2"
process "test","demo.en"

In my first test (*winqry) the messagebox showed 100, in the second (*winqry2) showed 0.

Am I missing something?

Hi Stéphane,

In queries I use the Initialization and Closing procedures, which are calls. To get any result from the query, I have to leave that call. This means dropping to a lower stack and loosing the local global I created in the call.

I think local globals are great, but I'm affraid they can't help in this situation.

Thank you for your suggestion.

Arno de Greef

Hi Stéphane,

This sounds interesting. Will have a look !

Thanks,
Arno de Greef

Hello,

We have created an object to read some information from our database. We would like to show this information in a column of a query. We want to create a new instance of the object when starting the query and drop the object when closing the query.

To do this, we're looking into the Initialization and Closing procedures on the interface tab of the query interface. During the initialization procedure we need create the object and make the objects CTL available to both a formula in the query itself and the closing procedure. To that end we tried normal (non global) variabeles. This seems to work file with classic queries, however in query+ queries the CTL can be used in the formula but does not arrive in the closing procedure. Naturally we could use a global variable, but we worry about the scope of these variables. Chances are we will use multiple (same) queries at the same time causing the risk of globals overwriting each other.

Is there anybody out there with experience in this matter who is willing to share  ?

Thanks,
Arno de Greef

It's hard to give advise without a more details about your program.

In general, I think this will take a bit more debugging. Assuming Excel is working normally outside PxPlus and this issue is Onedrive related, I would probably start by (temporary) placing the Excel file on another disc (surely outside Onedrive). Just to see what happens.

Cheers,

Arno de Greef

Hi Hans,

This sound like what happens when a file has not been synchronised from Onedrive to your machine. The system finds the file exists but when you try and open it from within PxPlus there's no content in the file, so Onedrive needs to download it. If there's no Onedrive connection processes may hang-up.

Cheers,
Arno de Greef

Hello,

My company has implemented Microsoft 365 and Onedrive. Within Windows Onedrive is working correctly, however from within PxPlus / WinDx we are experiencing some issues.

Everything seems to work fine when a file has been uploaded to Onedrive and has already been synchronised to my workstation.

When a file has been created on one machine and is opened in PxPlus / WinDx from another system (before files have been synchronised), I run into issues.
In this situation Onedrive will automatically start downloading the file (displaying a little popup). Meanwhile PxPlus goes to not responding. Waiting 15 minutes for a 20MB file does not help.
At this point the only way to resolve this seems to be forcefully ending PxPlus, but Windows will not allow this (acces denied) until I end the Onedrive application on my computer completely (forced).

Does anybody have experience with Onedrive from within PxPlus?

Cheers,

Arno de Greef