1
Support and Feedback / Re: Desc fields in MultiButtons XML file
« Last post by hacime on Today at 11:59:31 »to dynamically display button tooltips after changing the application language
News:
MultiCommander v15.8 is released!
Recent Posts
2
Support and Feedback / Re: Desc fields in MultiButtons XML file
« Last post by Mathias (Author) on Today at 08:59:23 »Why do you need to use text from language files for your personal config file. You can just write the text,
3
Support and Feedback / Re: Desc fields in MultiButtons XML file
« Last post by hacime on Today at 08:24:40 »thanks for quick reply, I wish something like <desc>#{ExplorerPanel:m,201}</desc> would be possible. Anyways, thanks for this great app.
4
Beta Releases / Re: MC V17 Early Access PREVIEW 3
« Last post by total_annihilation00 on Today at 08:23:46 »Don't find any issue with selection and checkboxes.. they are unselected.. Make sure you have configured it correctly.. that behavior is depending on Explorer Panel settings
Additional issues in v17:
- Selection isn’t cleared when clicking empty space: In v16, clicking an empty area of the file pane (for example, the area below the items in a folder with only a few files, as indicated by the red circle in the screenshot) deselects the checked items and the focused item. In v17, they remain selected.
- Back/Forward navigation is inconsistent: The Toolbar’s Back and Forward buttons sometimes navigate to an unrelated folder instead of the previous or next folder. I’ve encountered this a few times and will try to find a reproducible scenario.
**P.S.** The Column Layout is working flawlessly—thank you so much for implementing it! 😄
5
Support and Feedback / Re: Bug in image viewer
« Last post by Mathias (Author) on Today at 07:04:43 »WIC return WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE when it tried to load the file.
Since it is not my code I can't dig down to exactly what, AI also said it had bad metadata. and then I did not tell it what WIC also said that. so both of them say that.
I don't care exactly what in meta data is bad. It does not matter for me. It is not my code so I can't modify it anyway.
The code is part of Windows, All MC do is to use API calls provided by Windows. So if it is a bug in the loader. Then It is in Microsoft code. And I don't have access to that.
However, What I might be able to do is it add a fallback load method that will try to load the image without the metadata.
Told AI to analyze it again.. and to show where the error is, And it wrote script to validate it and gave this result
----------------------------------------------------
JPEG segments:
FFE0 at 2 len 16 b'JFIF\x00\x01\x01\x01\x00H\x00H'
FFFE at 20 len 63 b'CREATOR: gd-'
FFE1 at 85 len 2005 b'Exif\x00\x00II*\x00\x08\x00'
FFDB at 2092 len 67 b'\x00\x06\x04\x05\x06\x05\x04\x06\x06\x05\x06\x07'
FFDB at 2161 len 67 b'\x01\x07\x07\x07\n\x08\n\x13\n\n\x13('
FFC0 at 2230 len 17 b'\x08\x02\xbc\x01\xd3\x03\x01"\x00\x02\x11\x01'
FFC4 at 2249 len 31 b'\x00\x00\x01\x05\x01\x01\x01\x01\x01\x01\x00\x00'
FFC4 at 2282 len 181 b'\x10\x00\x02\x01\x03\x03\x02\x04\x03\x05\x05\x04'
FFC4 at 2465 len 31 b'\x01\x00\x03\x01\x01\x01\x01\x01\x01\x01\x01\x01'
FFC4 at 2498 len 181 b'\x11\x00\x02\x01\x02\x04\x04\x03\x04\x07\x05\x04'
SOS at 2681
TIFF header b'II' magic 42
[IFD0] at offset 8, 2 entries
0x0132 DateTime ASCII count=20 @38 b'2012:03:07 10:23:20\x00'
0x8769 ExifIFDPointer LONG count=1 inline (58,)
[ExifIFD] at offset 58, 0 entries
[IFD1 (thumbnail)] at offset 64, 3 entries
0x0103 Compression LONG count=1 inline (6,) <-- WRONG TYPE, expected SHORT
0x0201 JPEGInterchangeFormat LONG count=1 inline (106,)
0x0202 JPEGInterchangeFormatLength LONG count=1 inline (1891,)
PROBLEMS:
IFD1 (thumbnail) tag 0x0103 Compression: LONG count=1 <-- WRONG TYPE, expected SHORT
parsed the file's EXIF data with a script. One thing is actually wrong: the thumbnail's Compression tag is stored with the wrong data type.
The file is small (14,665 bytes, 700×467). It was saved by PHP's GD library (the comment says CREATOR: gd-jpeg), with a short EXIF block added afterwards
┌───────────────────┬────────────────────────────────────┬─────────────────┬──────────────────────────────────────────────────────┐
│ Block │ Tag │ Stored as │ Status │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0 (main image) │ DateTime = 2012:03:07 10:23:20 │ ASCII, 20 chars │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0 │ ExifIFDPointer → offset 58 │ LONG │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ Exif IFD │ (0 entries) │ — │ Empty but parses fine │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 (thumbnail) │ Compression = 6 (JPEG) │ LONG │ ❌ The EXIF/TIFF spec requires SHORT │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 │ JPEGInterchangeFormat = 106 │ LONG │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 │ JPEGInterchangeFormatLength = 1891 │ LONG │ OK; the thumbnail fits exactly inside the EXIF block │
└───────────────────┴────────────────────────────────────┴─────────────────┴──────────────────────────────────────────────────────┘
The value itself (6 = JPEG) is correct; only the type is wrong. Lenient readers like libexif, exiftool and browsers just read the number. WIC checks the type against its schema and returns WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE.
The rest of the file is fine: the JPEG structure, quantization and Huffman tables, and frame header are all valid.
----------------------------------------------------
and looking at http://www.fifi.org/doc/jhead/exif-e.html#IFD1Tags for spec
0x0103 Compression unsigned short 1 Shows compression method. '1' means no compression, '6' means JPEG compression.
Since it is not my code I can't dig down to exactly what, AI also said it had bad metadata. and then I did not tell it what WIC also said that. so both of them say that.
I don't care exactly what in meta data is bad. It does not matter for me. It is not my code so I can't modify it anyway.
The code is part of Windows, All MC do is to use API calls provided by Windows. So if it is a bug in the loader. Then It is in Microsoft code. And I don't have access to that.
However, What I might be able to do is it add a fallback load method that will try to load the image without the metadata.
Told AI to analyze it again.. and to show where the error is, And it wrote script to validate it and gave this result
----------------------------------------------------
JPEG segments:
FFE0 at 2 len 16 b'JFIF\x00\x01\x01\x01\x00H\x00H'
FFFE at 20 len 63 b'CREATOR: gd-'
FFE1 at 85 len 2005 b'Exif\x00\x00II*\x00\x08\x00'
FFDB at 2092 len 67 b'\x00\x06\x04\x05\x06\x05\x04\x06\x06\x05\x06\x07'
FFDB at 2161 len 67 b'\x01\x07\x07\x07\n\x08\n\x13\n\n\x13('
FFC0 at 2230 len 17 b'\x08\x02\xbc\x01\xd3\x03\x01"\x00\x02\x11\x01'
FFC4 at 2249 len 31 b'\x00\x00\x01\x05\x01\x01\x01\x01\x01\x01\x00\x00'
FFC4 at 2282 len 181 b'\x10\x00\x02\x01\x03\x03\x02\x04\x03\x05\x05\x04'
FFC4 at 2465 len 31 b'\x01\x00\x03\x01\x01\x01\x01\x01\x01\x01\x01\x01'
FFC4 at 2498 len 181 b'\x11\x00\x02\x01\x02\x04\x04\x03\x04\x07\x05\x04'
SOS at 2681
TIFF header b'II' magic 42
[IFD0] at offset 8, 2 entries
0x0132 DateTime ASCII count=20 @38 b'2012:03:07 10:23:20\x00'
0x8769 ExifIFDPointer LONG count=1 inline (58,)
[ExifIFD] at offset 58, 0 entries
[IFD1 (thumbnail)] at offset 64, 3 entries
0x0103 Compression LONG count=1 inline (6,) <-- WRONG TYPE, expected SHORT
0x0201 JPEGInterchangeFormat LONG count=1 inline (106,)
0x0202 JPEGInterchangeFormatLength LONG count=1 inline (1891,)
PROBLEMS:
IFD1 (thumbnail) tag 0x0103 Compression: LONG count=1 <-- WRONG TYPE, expected SHORT
parsed the file's EXIF data with a script. One thing is actually wrong: the thumbnail's Compression tag is stored with the wrong data type.
The file is small (14,665 bytes, 700×467). It was saved by PHP's GD library (the comment says CREATOR: gd-jpeg), with a short EXIF block added afterwards
┌───────────────────┬────────────────────────────────────┬─────────────────┬──────────────────────────────────────────────────────┐
│ Block │ Tag │ Stored as │ Status │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0 (main image) │ DateTime = 2012:03:07 10:23:20 │ ASCII, 20 chars │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD0 │ ExifIFDPointer → offset 58 │ LONG │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ Exif IFD │ (0 entries) │ — │ Empty but parses fine │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 (thumbnail) │ Compression = 6 (JPEG) │ LONG │ ❌ The EXIF/TIFF spec requires SHORT │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 │ JPEGInterchangeFormat = 106 │ LONG │ OK │
├───────────────────┼────────────────────────────────────┼─────────────────┼──────────────────────────────────────────────────────┤
│ IFD1 │ JPEGInterchangeFormatLength = 1891 │ LONG │ OK; the thumbnail fits exactly inside the EXIF block │
└───────────────────┴────────────────────────────────────┴─────────────────┴──────────────────────────────────────────────────────┘
The value itself (6 = JPEG) is correct; only the type is wrong. Lenient readers like libexif, exiftool and browsers just read the number. WIC checks the type against its schema and returns WINCODEC_ERR_PROPERTYUNEXPECTEDTYPE.
The rest of the file is fine: the JPEG structure, quantization and Huffman tables, and frame header are all valid.
----------------------------------------------------
and looking at http://www.fifi.org/doc/jhead/exif-e.html#IFD1Tags for spec
0x0103 Compression unsigned short 1 Shows compression method. '1' means no compression, '6' means JPEG compression.
6
Support and Feedback / Re: Bug in image viewer
« Last post by nietrupek on Today at 00:19:34 »MC do not decode jpg it self.. MC is using WIC (Windows Imaging Component) So I don't know if there is anything I can do about it.
So we can exclude MC itself. Problem lies either in WIC or in malformed file.
According to an AI analyze of the image
"The problem is its EXIF block (APP1, 2005 bytes). It contains a small thumbnail, and the thumbnail's Compression tag (0x0103) is written with type LONG instead of SHORT, which the EXIF spec requires."
Could you provide source of this information? I cannot reproduce it. There's no *long int* representation of 0x103 value in this file.
The command:
C:> hexdump -x plomyki.jpg
shows file content as 16-bits (short int) values. There are some "0103" values there, but no one has enough zeroes in their neighbourhood to form long int of this value.
As there may be not aligned longs in file, I also checked output of command:
C:> hexdump -X plomyki.jpg
This dumps file as bytes (2 hex digits, separated with double spaces). Searching for "03 01" sequences shows some results but again - there is not enough 00 bytes after them to form long int.
Besides, no software I have displays warning about malformed file. For example:
C:>exiftool -Compression -H plomyki.jpg
simply shows:
0x0103 Compression : JPEG (old-style)
without any warning about spec violation.
As this is my HI (Human Intelligence) analysis, I might have overlooked something. I am not JPEG expert.
7
Beta Releases / Re: MC V17 Early Access PREVIEW 3
« Last post by Mathias (Author) on Yesterday at 18:50:17 »Don't find any issue with selection and checkboxes.. they are unselected.. Make sure you have configured it correctly.. that behavior is depending on Explorer Panel settings
8
Support and Feedback / Re: Desc fields in MultiButtons XML file
« Last post by Mathias (Author) on Yesterday at 17:19:23 »the language in the ButtonPanel.xml are only matching against language texts in Multicommander_lang_<lang>.xml file.. not Explorer Panel,
9
Support and Feedback / Desc fields in MultiButtons XML file
« Last post by hacime on Yesterday at 15:30:29 »Hello,
I've made some modifications in button bar in this wonderfull application, I've 16 buttons in 2 rows.
In the last button which copies the path name tooltip does not show up.
What I want to achive is to get desc value {m,201} from ExplorerPanel_lang_en XML file, however, it just shows #{m,201} when hovering the button.
Any help would be appreciated.
Best regards.
I've made some modifications in button bar in this wonderfull application, I've 16 buttons in 2 rows.
In the last button which copies the path name tooltip does not show up.
What I want to achive is to get desc value {m,201} from ExplorerPanel_lang_en XML file, however, it just shows #{m,201} when hovering the button.
Any help would be appreciated.
Best regards.
10
Support and Feedback / Re: Bug in image viewer
« Last post by Mathias (Author) on Yesterday at 06:20:36 »Might be able to add a workaround for it.. If It fails because of metadata.. It might be able to read file into memory.. strip metadata.. and then load the image.