#133 closed bug (fixed)
Button Gadgets - missing image
Reported by: | Richard Lake | Owned by: | Thore Böckelmann |
---|---|---|---|
Priority: | normal | Milestone: | 4.0-2015R1 |
Component: | foreign application | Version: | 4.0-2014R5 |
Severity: | minor | Keywords: | |
Cc: | Andreas Falkenhahn | OS Platform: | All |
Blocked By: | Blocking: | ||
Release Notes: |
A to be underlined character passed by MUIA_Text_HiChar will now be treated like one passed by MUIA_Text_ControlChar. This has the advantage that the underlining does not corrupt possibly desired text styles by inserting artifical underline styles. Furthermore the to be underlined character will never be searched for in advanced features of the current text engine like ASCII addresses of embedded images. For example this happened for embedded ARGB images in MUIRoyale GUIs. |
Description
Summary
Referred by Andreas, Hollywood Developer:
http://forums.hollywood-mal.com/viewtopic.php?f=21&t=961
Steps to reproduce
Just happens randomily.
Expected results
Button Images to load. See first attached screenshot.
Actual results
See second attached screenshot.
Regression
Notes
From time to time, quiet randomily, my MUI application refuses to load images that I specified against a button. In the screenshot shown, there are many tabs and various GUI elements loaded into the application, but presently the Fold All and Unfold All buttons are the only ones seemily affected by this issue.
Further comments by Andreas and myself on the Hollywood forum via the link above.
Attachments (11)
Change History (51)
Changed 5 years ago by
Attachment: | Jack_ScreenCapture2.png added |
---|
Changed 5 years ago by
Attachment: | Jack_ScreenCapture4.png added |
---|
comment:1 Changed 5 years ago by
Component: | Gadget.mui → Imagespace.mui |
---|---|
Milestone: | → MUI 4.0-2014R6 |
Owner: | set to Thore Böckelmann |
Priority: | undecided → normal |
Status: | new → assigned |
comment:2 Changed 5 years ago by
Cc: | Andreas Falkenhahn added |
---|
comment:3 Changed 5 years ago by
According to the discussion in the Hollywood forum you are using something like "\033A[66]" to specify the image to be displayed. This is something which cannot work that way. "66" will be interpreted as an address of a struct MUI_AlphaData which is (privately) defined as
struct MUI_AlphaData { LONG width; LONG height; LONG dummy[2]; // 16-byte align for data ULONG data[0]; };
I don't know whether Hollywood modifies this before it is passed to MUI's text engine, but the address 0x66 should definitely cause some kind of DSI on AmigaOS4. Furthermore external images cannot be used at all like like, but only embedded raw ARGB images.
External images like those from AISS are to be used like this "\033I[5:TBIMAGES:list_fold]".
I admit that the MUI Autodocs are a bit outdated in this respect and don't mention stuff like 'A' for embedded raw ARGB data at all. I will add that ASAP.
comment:4 Changed 5 years ago by
Which image spec exactly are you using for you image buttons?
Is it possible that loading the images fails for any more or less obvious reason? When exactly does this happen? Right after opening the window for the first time? Or after deiconification as well?
The debug log of a failed try would definitely help.
comment:5 Changed 5 years ago by
@tboeckel: "\033A[66]" is just an escape code that is internal to MUI Royale. MUI Royale will parse this escape code and generate a correct one for MUI. I've verified that MUI Royale passes a correct image specification to MUI but still the images are sometimes missing. I can reproduce djrikki's problem with OS4.1 Update 5 on the Pegasos 2 but not on the X1000 running some beta components provided by ssolie. I'd suppose this is a bug in OS4, not in MUI. I remember having some strange refresh issues with MUI on OS4 before, but some of them have been fixed.
comment:6 Changed 5 years ago by
I cannot really imagine that OS4 should be at fault here. You can try the debug version of muimaster.library. It will output a warning on the serial line in case an invalid struct MUI_AlphaData is found. That output can be redirected to a file or a console using Sashimi.
MUI checks if the parsed address is a multiple of 4 and both width and height are between 0 and 1023. If that is the case the pointer is accepted, otherwise it is rejected.
comment:8 Changed 5 years ago by
I finally managed to test the MUIBuilder binary on AmigaOS4 myself. I does not work. First of all it must be named "MUI Builder" instead of "MUIBuilder". Second it complains about a missing file named "gui.xml". Please provide this one, otherwise I cannot help you.
A working AmigaOS3/68k build would still be very helpful. I can spend more time on WinUAE than on my uA1.
Changed 5 years ago by
Changed 5 years ago by
Attachment: | MUI Builder added |
---|
comment:9 follow-up: 11 Changed 5 years ago by
Unable to supply AmigaOS build, Hollywood complains that is not able to compile for this architecture - which is strange never had a problem before.
I've attached a LHA for your attention, should be everything included to launch MUI Builder under AmigaOS 4, ignore the other two attachments.
Changed 5 years ago by
Attachment: | MuiBuilder.lha added |
---|
comment:10 Changed 5 years ago by
Alternatively, LIstTree.lha is supplied, which is a smaller code snippet which exhibits the same behaviour.
comment:11 Changed 5 years ago by
Replying to djrikki:
Unable to supply AmigaOS build, Hollywood complains that is not able to compile for this architecture - which is strange never had a problem before.
I've attached a LHA for your attention, should be everything included to launch MUI Builder under AmigaOS 4, ignore the other two attachments.
According to Andreas you are most probably using a beta version which can build for AmigaOS4 only. You need to copy the file "Hollywood.sys" from the CD to "Hollywood:System". Then you should be able to build for AmigaOS3 again.
comment:12 Changed 5 years ago by
I will of course give that a go and hopefully have something for you by the weekend.
comment:13 Changed 5 years ago by
Hi, I've uploaded a newer version of MUI Builder that includes OS3 builds for non-FPU and FPU classics, please do not let me know if your machine has an FPU so I can save a little time next time around
Hope this helps.
PS. sorry I meant to replace the existing upload, didn't see case-sensitivity.
comment:14 Changed 5 years ago by
I don't know if you have AISS installed on Classic/WinUAE, but I highly recommend you do, MUI Builder depends on it thanks to the integration.
Changed 5 years ago by
Attachment: | HollywoodPlayer_541x121x32.png added |
---|
Error message of MUIBuilder FPU version
Changed 5 years ago by
Attachment: | HollywoodPlayer_543x121x32.png added |
---|
Error message of Listtree FPU version
comment:15 Changed 5 years ago by
Unfortunately both the FPU and the non-FPU version of MUIBuilder just produce this error message:
For Listtree I get a similar error about a missing brush:
Latest AISS 4.18 version is installed. Since I am using WinUAE for AmigaOS3 an FPU is always available.
Perhaps the error requester should include real names instead of brush numbers.
comment:16 Changed 5 years ago by
OK, that's fine I will be able to tell which images are missing from this error message.
comment:17 Changed 5 years ago by
Okay 21 is tbimages:screen, 54 has been included along with some more embedded brushes. Please recheck, also need to make sure your using the latest AISS.
comment:18 Changed 5 years ago by
AISS 4.18 is installed. But even SnoopDOS does NOT show a single access to any image file.
comment:21 Changed 5 years ago by
Sorry ignore me, its my stupid battery clock, it doesn't keep time and randomily goes back and forward in time after being turned on again after a few hours. Files re-uploaded.
Changed 5 years ago by
Attachment: | muibuilder_win_open_failure.png added |
---|
Error message of MUIBuilder failing to open its window
comment:22 Changed 5 years ago by
comment:24 Changed 5 years ago by
Haven't got time to look at the issue with ListTree this morning, work beckons. Code looks fine, lets concentrate on getting MUIBuilder OS3-friendly, its clearly past the stage of loading all brushes successfully.
comment:27 Changed 5 years ago by
Ahhh, now everything is running and even on AmigaOS3 the Fold/Unfold buttons are missing their images. I will investigate why this is happening.
Apart from that you should review your code. Setting a custom public screen for MUIBuilder works as expected, but any confirmation requester is still opened on the Workbench screen. The same happens for file requesters, i.e. when adding background images. Quite annoying…
comment:28 Changed 5 years ago by
Component: | Imagespace.mui → foreign application |
---|
Ok, here we go. It is definitely MUIRoyales fault. The passed image spec contains ESC characters plus some 'u' and 'U' characters within the address string:
adspec '11ueUab63c] Fold All' -> 00000011 -6092257 -6091745 31 31 1B 75 65 1B 55 61 62 36 33 63 5D 20 46 6F 6C 64 20 41 6C 6C ^^ ^^ ^^ ^^ adspec '11f3ucU994] Unfold All' -> 000011F3 1114112 884736 31 31 66 33 1B 75 63 1B 55 39 39 34 5D 20 55 6E 66 6F 6C 64 20 41 6C 6C ^^ ^^ ^^ ^^
What you see above is the image spec with the leading "\033A[" already skipped plus the parsed address, the resulting image width and height values and a hex dump of the string. Although a typical printf() call will show no obvious errors one can easily see that the address string contains some stray characters which don't belong there and cause the strtoul() function to bail out too early and return an invalid address. That's why MUI isn't able to obtain any image dimensions and later isn't able to draw the image.
Why is MUIRoyale using \033A for the images at all? Is this just for flexibility? For example, what about using \033I[TBIMAGES:resize] directly and letting MUI doing all the datatypes stuff?
Furthermore MUIRoyale does not handle the alpha channel correctly when loading the images. I get the typical pink background where the images should be transparent. MUI's internal image loading process handles this correctly (a suitable combination of picture.datatype and png.datatype provided). At least it is possible to obtain raw ARGB data from datatype objects with correct alpha channel even on AmigaOS3.
Please provide a working version of the Listtree demo. I'd like to know if this suffers from the same bug or if there is something different happening.
To sum it up: there is no bug in MUI regarding MUIBuilder, but it is MUIRoyale who is constructing an invalid address string.
comment:29 follow-up: 30 Changed 5 years ago by
RE: Custom Screen, observed.
I did request some additional custom screen functionality a while back which Andreas quite happily implemented in relation to MUI windows themselves, the ability to set any window, parent or child to a custom screen. However, system file requesters do not clearly follow suit in MUIBuilder.
This could be because MUIBuilder is still in development and hasn't been added into the code yet or it could be because its not part of Hollywood's functionality; yet.
I observed the same behaviour in Jack just now as a guinea pig test, perhaps Andreas can confirm whether this is currently possible and whether I have simply missed something out on both occasions.
comment:30 Changed 5 years ago by
Replying to djrikki:
RE: Custom Screen, observed.
I did request some additional custom screen functionality a while back which Andreas quite happily implemented in relation to MUI windows themselves, the ability to set any window, parent or child to a custom screen. However, system file requesters do not clearly follow suit in MUIBuilder.
EasyRequest() can open requesters on a custom screen by setting ESF_SCREEN in es_Flags and setting es_Screen accordingly, at least with intuition V50. For AmigaOS3 something custom has to be implemented. And ASL requesters can be opened on custom screens since ages.
comment:32 Changed 5 years ago by
Some final explanation from my side. The previous approach for underlining shortcut characters respected the old and simple escape sequences (i.e. \033b for bold text) which consisted of a single character after the ESC only and inserted additional artificial sequences for underlining. This worked quite ok as long as the to be underlined character did not occur within a larger text section to be underlined, because the artificial \033U caused the underlining to end too early. That is why MUIA_Text_ControlChar was introduced which lets MUI's text engine draw a line below the given character using Move() and Draw() instead of relying on soft styles. The behaviour of MUIA_Text_HiChar was kept for compatibility (I think).
When the advanced sequences were introduced (i.e. \033A[deadbeef] or \033P[--ff0000]) this mechanism of inserting artificial underline sequences was not extended to respect these new sequences and now it could happen that an application used something like this:
MUIA_Text_Contents, "\033A[deadbeef] Text", MUIA_Text_HiChar, 'e', ...
This should have underlined the character "e" within the word "Text", but because the escape sequence was not treated as such the underline escape sequence was falsely inserted into the address part and hence caused the image to disappear because of the now invalid image address. In the worst case this could have caused crashes due to invalid memory accesses.
Now MUIA_Text_ControlChar and MUIA_Text_HiChar are treated equally with a preference for MUIA_Text_ControlChar if both are specified.
I hope this explains the issue good enough. If the Listtree demo should still suffer from missing images then please provide a working AmigaOS3 binary in ticket #132. A confirmation whether the missing listtree images are fixed now is highly appreciated in any case.
comment:33 Changed 5 years ago by
So just to make this clear for djrikki and the record: It was a bug in MUI, not in MUI Royale.
comment:34 Changed 5 years ago by
that's how i understood it as well, Andreas please still check the custom screen comment above thanks guys
comment:35 follow-up: 36 Changed 5 years ago by
Alright, I just wanted to point this out again since above it was said that…
It is definitely MUIRoyales fault
…which turned out to be wrong. I usually do my homework before claiming it is an OS4 or MUI bug, as this case shows
Btw, the bug's quite serious and can take down the whole application so everyone better install a fixed MUI. If just the image is missing you can actually consider yourself pretty lucky, because it could also crash completely.
comment:36 Changed 5 years ago by
Replying to afalkenhahn:
It is definitely MUIRoyales fault
…which turned out to be wrong. I usually do my homework before claiming it is an OS4 or MUI bug, as this case shows
Remember your mail from January 15th?
TB>> Deswegen will ich ja ein OS3-Binary, eben zum Gegenprüfen.
AF> Hmm, gute Idee… ich prognostiziere, dass es funktionieren wird
A quick translation for the non-german people among us:
TB>> That's why I want an OS3 binary, for checking.
AF> Good idea. I predict that it will work.
At that time you were still convinced that it was a bug in AmigaOS4 only and that AmigaOS3 would not be affected. Don't get me wrong, I really don't want to point fingers at anybody. Everybody can make mistakes and at first this issue very much looked like a bug outside MUI. I have no problem to admit that I was wrong with suspecting MUIRoyale. Finally I am glad that we found the solution by working together instead of blaming each other to guilty of this or that.
Btw, the bug's quite serious and can take down the whole application so everyone better install a fixed MUI. If just the image is missing you can actually consider yourself pretty lucky, because it could also crash completely.
That's true. Did anybody check how MUI/MorphOS reacts in this case? Given the fact that their MUI version inherits the same roots they could face exactly the same problems.
comment:37 Changed 5 years ago by
At that time you were still convinced that it was a bug
in AmigaOS4 only and that AmigaOS3 would not be affected
True, but honestly, the only thing that was really sure for me was that it couldn't be a bug in MUI Royale because I verified that strings are generated and passed correctly. After this verification I posted the following in the Hollywood forums (already on December 30th):
I can reproduce this behaviour but it looks like it is
a MUI bug. I've verified that MUI Royale passes the string
correctly to the MUI object and that the image data is
correctly formatted. You should report this to the MUI developers.
http://forums.hollywood-mal.com/viewtopic.php?f=21&t=961#p4625
So my first diagnosis was a MUI bug
Not sure if the problem is there on MorphOS as well… will check this in the near future…
comment:38 Changed 5 years ago by
@djrikki:
The requester issue with custom screens has been fixed now.
comment:39 Changed 5 years ago by
Release Notes: | modified (diff) |
---|
Please install the debug version of muimaster.library and create an IMAGE debug log with that version.
Details of the debug version can be found in the FAQ.