I have a serious problem with foreign characters in Msg in OI 3.61 - characters that have worked fine earlier - at least until and including 3.3.

Earlier one just had to avoid the 6 last characters - the system delimiters. Now also the 5 characters before that are affected. These characters include characters from the Norwegian and Swedish alphabet. I must stress that these are absolutely necessary characters, as frequent and necessary as e.g the "w" in English. To substitute other characters would be even less acceptable than e.g using "vv" instead of "w" in English. (Hovv vvould you like that, by the vvay?) Using uppercase is no good idea either if you don't specifically want that stone age application look.

What happens here if I try to use characters 245-249 in the Msg text or caption is the following: In the caption chars 245-248 are converted to chars 250-253. In the text they become newlines. Char 249 messes up even more. It brings up the debugger (MSG. Line 1. Non-numeric data etc) or changes the font or adds a help button to the message box. My worry is char 248. The Swedes need 246.

I just upgraded from 3.3 and didn't check the versions inbetween (3.4 and 3.5), so I don't know exactly when the error was introduced.

There is of course a slight chance that the error is local - that it has to do with my international settings, but I don't really think so. They have worked like a charm until now. But could somebody please test this on an English system to make sure? (And what about you guys from Sweden? Haven't you noticed anything?)

Here are the problematic characters (at least if square brackets work for html entities as well as for codes. Or else you can e.g look them up in Word. Use Insert | Symbol, select Normal Text and look at the last row of the symbol table):

Char 245 - õ.

Char 246 - ö.

Char 247 - ÷.

Char 248 - ø.

Char 249 - ù.

- Oystein -

Øystein Reigem, Humanities Information Technologies, Harald Haarfagresgt 31, N-5007 Bergen, Norway. Tel: +47 55 58 32 42. Fax: +47 55 58 94 70. E-mail: [email protected]

Oystein

Why not use the CHARMAP stuff from the latest SENL now available on-line as an HTML doc

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

Thanks, Andrew! I wasn't aware of the improved CHARMAP. I hadn't read the latest SENL yet. I assume the improved CHARMAP must have been mentioned in the OI upgrade README's too, but again I've only read the ones for 3.4 and 3.5 and not for 3.6. (Well, for me improvements in handling foreign characters are so important they'd deserve special bulletins on the Web Discussion. I don't know how all the other "foreign" developers feel.)

But - I need to know all the consequences before I start to use CHARMAP:

(1) My users have to run existing data through a conversion to the new internal representation - right? (And I must make sure they do it once and only once. ) (And one must make certain that SwapDelimiters function in your article isn't run twice either. Well, I assume it must be run once at start-up.)

(2) I understand I must change my collation sequence in accordance with the new character map. Does that go for all of the internatinonal settings?

(3) Can I still use OIPI? Does OIPI use the new CHARMAP? OIPI is vital for our users.

(4) We don't use the Reporter, but some of our users still use Report Builder. Does RB use the new CHARMAP? (Hardly, I'd guess.)

(5) When will the System Editor (specifically the Result Viewer) catch up?

(6) What else did your article forget to tell me?

But no matter what the answers to the above are I think RevSoft must fix the problem with Msg. Cameron, Gene, et al - can I have your opinion, please!

- Oystein -

Øystein Reigem, Humanities Information Technologies, Harald Haarfagresgt 31, N-5007 Bergen, Norway. Tel: +47 55 58 32 42. Fax: +47 55 58 94 70. E-mail: [email protected]

Char 245 -õ

Char 246 - ö

Char 247 -÷

Char 248 - ø

Char 249 - ù

- O -

Hi Oystein,

I don't know what changed. Any idea what doesn't work? You do have the source if you need to debug it.

Cameron Purdy

Revelation Software

Oystein,

I can't see anything in MSG that would cause that. Could you step through it in the debugger or post the binary of your message definition that messes up? (Or code that reproduces it?)

Cameron Purdy

Revelation Software

Cameron,

I can't see anything in MSG that would cause that. Could you step through it in the debugger

I stepped and to me everything looked normal. The values with the problematic characters (text () and caption ()) were delivered safely from MsgRec to MsgDef and not changed in any way when MsgDef got the default values filled in, but when Dialog_Box was called in line 271 I couldn't follow the process further. So it's your turn.

or post the binary of your message definition that messes up? (Or code that reproduces it?)

I didn't say so in the first posting but I tried both to make and test run a message in UI Workspace, and to run one programmatically. Both attempts failed in the same way.

The code is very simple:

$insert Msg_Equates

Meld             =1ñ2ò3ó4ô5õ6ö7÷8ø9"

Meld=200

Meld  =1ñ2ò3ó4ô5õ6ö7÷8ø9"

call msg( @Window, Meld )

The width spec is there so I can see the whole of the caption. I don't need all of the foreign characters above to see the effect. The following is enough to see how it fails on message text:

call msg( @Window, "1ø2" )

If you still want me to post a binary msg record I can.

By the way - I have this different but related problem with foreign characters in quickevent parameters, but that is not a new problem. I'll post a separate message about that.

- Oystein -

Oystein,

… but when Dialog_Box was called in line 271 I couldn't follow the process further …

Not true … the CREATE event will call MSG again … just put a break point on the ON GOSUB statement.

Cameron Purdy

Revelation Software

Cameron,

Not true … the CREATE event will call MSG again … just put a break point on the ON GOSUB statement

Then I have to recompile Msg (with a debug statement in it), right? You'll have to tell me how. I just get "SYS1224: The procedure cannot be overwritten." I imagine I should do it in SYSPROG rather in my app, but it makes no difference.

- Oystein -

Just remove MSG from SYSPROCNAMES (?) in SysEnv and log out and back in and it should recompile.

[email protected]

Sprezzatura Ltd

World Leaders in all things RevSoft

Oystein,

First, compile MSG only in SYSPROG.

Second, make sure it is not in SYSENV/SYSPROCNAMES. If it is, remove that line and restart OpenInsight. This list of stored procedures is used by the repository and compiler to prevent accidental over-writing of system procedures and it is used by the program loader to suppress the inheritance mechanism for system procedures (i.e. if a name is in the list, RTP27 will only look in SYSOBJ for "$" plus the name of the procedure regardless of the current application).

Third, open and compile MSG in the System Editor.

Fourth, don't put a "DEBUG" statement in just in case you get in an infinite loop. Instead, open the debugger, select File - Break (if necessary) then File - Open Stored Procedure and choose MSG. Use F9 to put a break-point on the ON GOSUB line of code, (later, you can use F9 to clear the breakpoint as well). You can use Search - Find to search for the the ON GOSUB.

Cameron Purdy

Revelation Software

Cameron,

Followed your instructions. The second time Msg is called (according to you from the dialog's CREATE), MsgRec has been altered. E.g, I had a char(248) in my msg text, and that had been changed to a @VM.

Your turn.

- Oystein -

Oystein,

Can you write the smallest program that shows the problem and post it here. I will try to reproduce it.

Thanks,

Cameron Purdy

Revelation Software

Cameron,

Can you write the smallest program that shows the problem and post it here.

But I already did. This posting contains two small programs. The second one should be small enough for you. And please feel free to try with other characters than the "ø".

- øystein -

View this thread on the forum...