[Bug] Multiple errors on launch regarding image file datatypes

[ghost]

Submission type

• Bug report

YAM version

[2.9p1]

Used operating system

• AmigaOS3/m68k

Used Amiga system

[OS 3.1.4]

Expected behaviour you didn't see

[No errors regarding image file loading]

Unexpected behaviour you saw

The following is displayed in an error dialog box when YAM is launched:

An error occurred while trying to load the image file 'PROGDIR:Resources/Themes/default/config/config_update_big' via datatypes. Please make sure that the file exists and that you have your datatypes system correctly set up (e.g. that the image displays properly with MultiView).

Steps to reproduce the problem

Simply launch YAM on OS 3.1(.4) after a fresh install of YAM. That is all. I used SnoopDOS to find that YAM was looking for binary.datatype, so I downloaded it from aminet[1] but this is possibly not the correct version as it displays HEX in multiview for files such as config_update_big. Without a file extension on config_update_big, I don't know what to provide.

1: http://aminet.net/package/util/dtype/binarydt_39.11

[tboeckel]

It is not YAM directly who looks for binary.datatype, but motst probably datatypes.library itself, but within the context of YAM's process.
YAM just expects that all the images can be loaded via datatypes.library. Which datatype in the end is used to load a specific image is beyond YAM's scope. This decision is made by datatypes.library alone. For YAM's default images you need a PNG datatype, like http://aminet.net/package/util/dtype/akPNG-dt.

It might happen that two datatypes both claim to be able to handle one specific file and then again it is up to datatypes.library to decide which datatype eventually is being using to load the file. And since png.datatype and binary.datatype produce completely different representations of the loaded file (image vs. text) it is obvious why YAM complains about being unable to load an image if it is processed by binary.datatype. And this is exactly what you experience here. Even MultiView displays the file as textual hex dump instead of as graphic.

So, as YAM's error message suggests, make sure that the mentioned image can be loaded and displayed correctly by MultiView. And to make sure that binary.datatype does not interfere anywhere better deactivate it by either completely uninstalling it or at least by disabling it (move its icon from SYS:Devs/DataTypes to SYS:Storage/DataTypes and reboot).

[ghost]

Ah .. you are right. Thank you. The datatype was installed in System:classes/datatypes but not System:devs/datatypes. I have reinstalled and now it works.

Thank you once more.

[tboeckel]

Just choose the "empty" theme instead of "default".

Config -> Look&Feel -> Choose "empty" theme -> Activate

[ghost]

I tried just now and selected "empty" theme. With both "save" and "use", the application always reverts to "default". Even after close application and reopen.

[tboeckel]

Did you activate the "empty" theme? Just "using" or "saving" it is not sufficient.

[ghost]

I need to start using the scroll bars :) There is an ‘activate’ button on that pane but I hadn’t scrolled it into view. It works nicely, thank you.

…

On 16 Iúil 2019, at 06:24, Thore Böckelmann ***@***.***> wrote: Did you activate the "empty" theme? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#679?email_source=notifications&email_token=AANNESBEMR6DYSYLA5I2XQ3P7VLPXA5CNFSM4H4JIQB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ7XMOI#issuecomment-511669817>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANNESHQ4XN4P6PW72B42LLP7VLPXANCNFSM4H4JIQBQ>.