M
Mike Fechner
Guest
OpenEdge 11.1 Given the following scenario: OpenEdge GUI for .NET Client and AppServer, CPINTERNAL utf-8, Database code page also utf-8. In parallel TTY clients on UNIX running single byte code pages. In areas of the application that are relevant for compability with the legacy TTY application we need to ensure (validate) that character data entered on some of the GUI screens does not cause code page issues (and if it's just that characters are lost) in terminals or other output) in the legacy application. So for some tables/fields we need to avoid, that users in the GUI for .NET Application can enter characters that do not fit into a TTY applications code page. As an example, I may need to avoid that certain text fields contain Turkish special characters, because the TTY application running iso8859-1 could not handle them. What's the best way to validate this? I'm not keen parsing strings myself and validating ASC values of each character in question. One solution would be to try to assign the CHARACTER in question to a LONGCHAR fixed to iso8859-1 and see if that throws an error. ROUTINE-LEVEL ON ERROR UNDO, THROW. /* *************************** Main Block *************************** */ DEFINE VARIABLE cTest AS CHARACTER NO-UNDO. DEFINE VARIABLE lcTest AS LONGCHAR NO-UNDO. cTest = CHR (50591, "utf-8") . /*cTest = "ä" .*/ MESSAGE cTest SKIP ASC (cTest) SKIP VIEW-AS ALERT-BOX. FIX-CODEPAGE (lcTest) = "iso8859-1" . /*FIX-CODEPAGE (lcTest) = "1254" .*/ DO ON ERROR UNDO, THROW: /* Attempt to assign cTest to LONGCHAR fixed to iso8859-1 */ lcTest = cTest . CATCH err AS Progress.Lang.Error: IF err:GetMessageNum (1) = 142 THEN MESSAGE "Codepage problem...." VIEW-AS ALERT-BOX. ELSE UNDO, THROW err . END CATCH. END. MESSAGE STRING (lcTest) SKIP cTest ASC (cTest) VIEW-AS ALERT-BOX. Are there other solutions? Solutions that work for a complete temp-table record or ProDataset at once?
Continue reading...
Continue reading...