Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#201 closed bug (fixed)

File name limitation in external picture in MUIA_Image_Spec ?

Reported by: Guillaume Boesel Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R2
Component: foreign class Version: 4.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

Trying to add pictures in a NList by using "\33I[5:filename]", filename ≥ 69 chars seems to failed.
Filenames ⇐ 68 chars are OK

see attached pictures

Steps to reproduce

  1. Load a picture with 69 chars long name, for example : [5:Envarc:zzd10h/FastView_cache/Vincent_Classe_2013_02_1234567890.jpg]

picture will not be displayed

  1. Load a picture with 68 chars long name, for example : [5:Envarc:zzd10h/FastView_cache/Vincent_Classe_2014_01_123456789.jpg]

picture will be displayed

Expected results

Pictures with names ≥ 69 chars should be displayed

Actual results

Pictures with names ≥ 69 chars are not displayed

Of course, I tried the failing picture with a ⇐ 68 file name, it was displayed correctly.

Notes

Thank you

Attachments (3)

FastView_Capture_15-04-26_203621.JPG (326.8 KB) - added by Guillaume Boesel 5 years ago.
NList_large_buffer.lha (137.4 KB) - added by Thore Böckelmann 5 years ago.
NList.mcc 20.139 with large image name buffer
FastView_Capture_15-04-27_203729.JPG (329.0 KB) - added by Guillaume Boesel 5 years ago.

Download all attachments as: .zip

Change History (15)

Changed 5 years ago by Guillaume Boesel

comment:1 Changed 5 years ago by Thore Böckelmann

Component: Image.muiforeign class
Milestone: 4.0-2015R2
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

First of all your report is quite misleading. You are talking about "MUIA_Image_Spec" and "Image.mui", but in the end you are only referring to NList.mcc and none of the summary's keywords. This made me look in the complete wrong location in the first place. The fact that you are really referring to the 3rd party class NList.mcc also means that this bug report should have been reported in the NList bugtracker, even if the same range of developers is involved in both project.

But yes, NList.mcc has in internal temporary buffer for images names of 64+4 bytes. That's why longer names get truncated. It is easy to fix this, but it will take some time until the next NList release is done.

comment:2 Changed 5 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

Fixed in revision 761 of the NList project:

* nlist_mcc/private.h: increased the image name buffer size from 68 to 256 characters. This avoids very long file names to be truncated too early. This closes MUI ticket #201.

comment:3 Changed 5 years ago by Guillaume Boesel

Sorry for the misleading report.

And thank you for the fix.

When you say "it will take some time until the next NList release is done", how many time will it takes to release this new release ? Some weeks, some months ?

Thank you
Guillaume

comment:4 in reply to:  3 Changed 5 years ago by Thore Böckelmann

Replying to zzd10h:

When you say "it will take some time until the next NList release is done", how many time will it takes to release this new release ? Some weeks, some months ?

Months are more probable than weeks. The point is that the issue is absolutely no serious issue. The former buffer size has been in there since several years now without anybody noticing it being too small. Unless there are no further issues there is no reason to do an immediate new release.

However, you can build NList privately yourself. It builds natively on AmigaOS as well as on a Unix system using a cross compiler.

comment:5 Changed 5 years ago by Guillaume Boesel

"However, you can build NList privately yourself"

I just tried to compile it under OS4.

1) For info, it seems that the directory "common" is not included in the svn but is referenced in nlist_mcc/Makefile.dep and nlist_mcc/library.c for examples.

gmake[1]: stat: /common: Device not configured

#include "../common/NListviews_locale.h"

2) nbitmap_mcc/NBitmap.c references a "#include <graphics/minterm.h>" that doesn't exist in my SDK (latest official one).

Thank you

comment:6 in reply to:  5 Changed 5 years ago by Thore Böckelmann

Replying to zzd10h:

1) For info, it seems that the directory "common" is not included in the svn but is referenced in nlist_mcc/Makefile.dep and nlist_mcc/library.c for examples.

gmake[1]: stat: /common: Device not configured

#include "../common/NListviews_locale.h"

Hm, gmake should correctly handle Unix paths, at least it always did before for me.

2) nbitmap_mcc/NBitmap.c references a "#include <graphics/minterm.h>" that doesn't exist in my SDK (latest official one).

Argh. Yes, you are right. We had to use some stuff of the yet unreleased SDK, because our build server is kept in sync with the AmigaOS4 SVN repository.

I will provide a fixed version of NList.mcc in a few minutes. All other classes are unaffected by my change.

Changed 5 years ago by Thore Böckelmann

Attachment: NList_large_buffer.lha added

NList.mcc 20.139 with large image name buffer

comment:7 Changed 5 years ago by Guillaume Boesel

Yes gmake works for me, it's just than "common" directory is not present in the svn tree.

By the way, your new nlist 139 works very well.

Many thanks

Changed 5 years ago by Guillaume Boesel

comment:8 in reply to:  7 Changed 5 years ago by Thore Böckelmann

Replying to zzd10h:

Yes gmake works for me, it's just than "common" directory is not present in the svn tree.

The "common" directory is intentionally left out, because it is created dynamically during the build process.

comment:9 Changed 5 years ago by Guillaume Boesel

It's not a problem because you built a new nlist but I retried.

"Common" directory is well created but "stat" fails.

I just tried with "make os=os4".

Last edited 5 years ago by Guillaume Boesel (previous) (diff)

comment:10 in reply to:  9 Changed 5 years ago by Thore Böckelmann

Replying to zzd10h:

It's not a problem because you built a new nlist but where to find "./common/NListviews_locale.h" for example if "common" is not published ?

That file is created when building NListviews.mcp. That's why the toplevel Makefile builds the single classes in a very specific order.

The reason is that NList.mcc uses 4 or 5 translatable strings which are not worth to create a new catalog for them. Hence NList.mcc uses NListviews.catalog. The required source files are part of NListviews.mcp or are created during its build process. Therefore NListviews.mcp must be built before NList.mcc to create all required files.

BTW: the correct command line is

make OS=os4

with an upper case "OS". Using a lower case "os" does not hurt in your case, because "OS=os4" is the default, but you will surely fail if you intend to build for other platforms.

comment:11 Changed 5 years ago by Guillaume Boesel

I edited my previous post when you replied to it.

""Common" directory is well created but "stat" fails."

I will retry this evening with "OS=os4" and under 4.1.6.

comment:12 Changed 5 years ago by Guillaume Boesel

Same problem under 4.1.6 even in a sh shell…

Last edited 5 years ago by Guillaume Boesel (previous) (diff)
Note: See TracTickets for help on using tickets.