Weird encoding issue

Discuss GUI programming with the MUI Royale plugin here
Post Reply
User avatar
jPV
Posts: 675
Joined: Sat Mar 26, 2016 10:44 am
Location: RNO
Contact:

Weird encoding issue

Post by jPV »

If I'm using ISO8859-1 encoding with MUIRoyale, it behaves differently if the muiroyale.hwp file is in the progdir or in libs...

If you compile the following code as an executable and run it from a dir that also contains the muiroyale.hwp file, the listview entry is shown correctly. But if I remove the plugin from the progdir and have it on libs:hollywood/ then the listview entry is shown as question marks.

This happens at least on MorphOS and OS4... any idea why?

Code: Select all

@OPTIONS {Encoding = #ENCODING_ISO8859_1}
@DISPLAY {hidden=True}
@REQUIRE "muiroyale"

s$ = "öäéèçà"

Function p_EventFunc(msg)
   Switch msg.Class
   Case "Window":
      Switch msg.Attribute
      Case "CloseRequest":
         End
      EndSwitch
   EndSwitch
EndFunction

gui$ = [[<?xml version="1.0" encoding="iso-8859-1"?>
<application base="HELLOWORLD">
   <window title="Example GUI" muiid="MAIN" notify="closerequest">
      <vgroup>
         <listview id="lv">
            <column/>
         </listview>
      </vgroup>
   </window>
</application>]]

mui.CreateGUI(gui$)

mui.DoMethod("lv", "Insert", "Bottom", s$)

InstallEventHandler({MUIRoyale = p_EventFunc})

Repeat
   WaitEvent
Forever
SamuraiCrow
Posts: 475
Joined: Fri May 15, 2015 5:15 pm
Location: Waterville, Minnesota USA

Re: Weird encoding issue

Post by SamuraiCrow »

Uh, are there two different versions of the MUIRoyale plugin being used? ;)
I'm on registered MorphOS using FlowStudio.
User avatar
jPV
Posts: 675
Joined: Sat Mar 26, 2016 10:44 am
Location: RNO
Contact:

Re: Weird encoding issue

Post by jPV »

Nope...
User avatar
airsoftsoftwair
Posts: 5626
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: Weird encoding issue

Post by airsoftsoftwair »

I think this might have been fixed already by this fix, which was also reported by you:

Code: Select all

- Fix: Plugin is now de-initialized correctly in the rare case that it is loaded several times from different locations 
I can't seem to find the corresponding thread, though. Did you report this via email or PM?
User avatar
jPV
Posts: 675
Joined: Sat Mar 26, 2016 10:44 am
Location: RNO
Contact:

Re: Weird encoding issue

Post by jPV »

Hmm.. I don't remember where I'd reported it.. didn't find it quickly either :)

But more about plugins and encoding... I was reported that one of my previous programs crashes nowadays, and I hunted it down that it happens if you have the new RapaGUI 2.0 plugin installed to libs:hollywood/ and the program loads it automatically (compiled with pre-9.0 and no SKIPPLUGINS tooltype). This doesn't happen if the plugin is in the progdir, but when it's in the libs... and it happens only if I'm using ISO8859-1, so sounds somehow related...

Here's a very short example:

Code: Select all

; This crashes with HW8 (and exes compiled with it) if you have Libs:Hollywood/rapagui.hwp (version 2.0)
; It doesn't crash if the plugin is in the progdir or if the plugin is an older than 2.0
@OPTIONS {Encoding = #ENCODING_ISO8859_1}
WaitLeftMouse()
So, the annoying thing is that this affects to older compiled and distributed software. Is there something that could be fixed in the RapaGUI plugin for this?
User avatar
airsoftsoftwair
Posts: 5626
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: Weird encoding issue

Post by airsoftsoftwair »

jPV wrote: Mon Sep 27, 2021 4:53 pm So, the annoying thing is that this affects to older compiled and distributed software. Is there something that could be fixed in the RapaGUI plugin for this?
Yes, these are the bugs straight from hell. The problem is that I don't test ISO 8859-1 mode much any more because it has been obsolete since Hollywood 7 and now it's coming back at me. I've fixed it now but the fact that RapaGUI 2.0 crashes all executables that use ISO 8859-1 mode and were compiled by Hollywood versions > 6 and < 9 is of course pretty unacceptable so I guess I have to release a RapaGUI update rather sooner than later. :?

Code: Select all

- Fix [Amiga]: Hollywood versions 7.x and 8.0 crashed when trying to load RapaGUI 2.0 when the script
  was requesting ISO 8859-1 mode
User avatar
jPV
Posts: 675
Joined: Sat Mar 26, 2016 10:44 am
Location: RNO
Contact:

Re: Weird encoding issue

Post by jPV »

airsoftsoftwair wrote: Sun Sep 19, 2021 2:45 pm I think this might have been fixed already by this fix, which was also reported by you:

Code: Select all

- Fix: Plugin is now de-initialized correctly in the rare case that it is loaded several times from different locations 
I can't seem to find the corresponding thread, though. Did you report this via email or PM?
And about the original report in this thread, it isn't about loading several times... if I have muiroyale.hwp _only_ in libs then it's question marks, but if I have muiroyale.hwp _only_ in progdir, then it works. So it's about location even if there's just one plugin file to load.
User avatar
airsoftsoftwair
Posts: 5626
Joined: Fri Feb 12, 2010 2:33 pm
Location: Germany
Contact:

Re: Weird encoding issue

Post by airsoftsoftwair »

jPV wrote: Sat Oct 02, 2021 10:14 pm And about the original report in this thread, it isn't about loading several times... if I have muiroyale.hwp _only_ in libs then it's question marks, but if I have muiroyale.hwp _only_ in progdir, then it works. So it's about location even if there's just one plugin file to load.
Ok, this should be fixed now. The problem is related to the fact that starting with Hollywood 9.0, compiled executables no longer automatically load plugins from LIBS:Hollywood but only the ones in the PROGDIR:. If the plugin is not in the PROGDIR: the @REQUIRE preprocessor command will load it from LIBS:Hollywood but this happens at a later time than when plugins are initially loaded and so plugins loaded at that later time didn't get informed correctly about the text encoding in use.

Code: Select all

- Fix [Amiga]: Plugins in LIBS:Hollywood loaded by executables compiled by Hollywood that used ISO 8859-1 encoding weren't informed about the text encoding
Post Reply