Opened 6 years ago
Closed 12 months ago
#14693 closed bug (fixed)
ShowImage > Save as.. doesn't working
Reported by: | miqlas | Owned by: | leavengood |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | Applications/ShowImage | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #17527, #18662 | |
Platform: | x86-64 |
Description
Reproducible as follows:
- open an image
- Select Save as, any format
- Save it
No error shows up, but no output file created either.
Tested on 64 bit, hrev52501
Change History (16)
comment:1 by , 6 years ago
comment:3 by , 6 years ago
I will try to test this on a 64-bit image in the next few months. If anyone else happens to reproduce it in the meantime, please post a comment. Bugs which only pop up in 64 bit are fun.
comment:4 by , 6 years ago
I have tested this on a 64-bit hrev53001 image and it is definitely happening. It is inconsistent though, which is annoying. It does sometimes save an image, but many times does not. I'll work on debugging it to see why.
comment:5 by , 3 years ago
Blocking: | 17527 added |
---|
comment:6 by , 3 years ago
Still present on hrev56078, x86-64.
I can use "translate", like this: > translate Matrix.ico test.bmp 'BMP '
, and it properly creates a .bmp version of the original Windows .ico file.
Attempting to do the same using ShowImage "Save As..." does nothing (not even a peep).
comment:7 by , 3 years ago
Milestone: | Unscheduled → R1/beta4 |
---|
comment:8 by , 3 years ago
This might be of interest:
If I open in ShowImage the mentioned Matrix.ico, use "Select All" from the Edit menu, and "drag-and-drop" it, with the secondary mouse, into a Tracker window... a pop-up menu appears allowing the creation of a "Blitmap Clip" using the available translators.
I've tested several, all seem to create a valid "Bitmap Clip" in the selected format.
Even selecting parts of the image (instead of "Select All") seems to work (at least within the confines of the translator's capability (you can't drag-and-drop, via primary mouse button, a sub-selection of the mentioned .ico file, it fails with "The file 'Bitmap Clip' could not be written", despite the file actually appearing on Tracker, but with "application/octet-stream" file type, and "bits" as its first four bytes content).
follow-up: 10 comment:9 by , 3 years ago
Dragging and dropping into Tracker and "Save As..." generally use different code paths, so just because dragging and dropping work doesn't mean "Save As..." will as well.
I would suspect the error from dragging of the selection of an ico could be a file format or translator limitation. I am quite sure dragging and dropping a selection from bmp, png or jpg should work.
comment:10 by , 3 years ago
Replying to leavengood:
I guess I was not clear enough (my English is poorly self-taught). Sorry about that.
Dragging and dropping into Tracker and "Save As..." generally use different code paths, so just because dragging and dropping work doesn't mean "Save As..." will as well.
And that's why I mentioned, because it shows that at least one of those actually works (Drag-and-Drop), and might help understand why the other doesn't (Save-as).
(Edit: NOW I get it that the drag-and-drop working might be just Tracker handling things instead of StyledEdit as I initially thought :-/)
I would suspect the error from dragging of the selection of an ico could be a file format or translator limitation.
Yes, that's why I wrote "at least within the confines of the translator's capability". It was while having that .ico format limitation in mind. I guess I should have just that part out of my comment.
I am quite sure dragging and dropping a selection from bmp, png or jpg should work.
It does indeed! Again, sorry if it sounded like I was implying otherwise.
comment:11 by , 3 years ago
Milestone: | R1/beta4 → Unscheduled |
---|
Moving various tickets out of the beta4 milestone because no one is actively working on them.
comment:12 by , 13 months ago
Blocking: | 18662 added |
---|
comment:13 by , 13 months ago
Found the problem:
ShowImageWindow.cpp, line 1233:
translator_id outTranslator; uint32 outType; if (message->FindInt32(kTranslatorField, reinterpret_cast<int32 *>(&outTranslator)) != B_OK || message->FindInt32(kTypeField, reinterpret_cast<int32 *>(&outType)) != B_OK) return;
outTranslator isn't initialized correctly this way (due to type mismatch on 64 bit platform, I guess). We need to use a temporary int32 variable and then assign its value to outTranslator.
This works:
int32 outTemp; uint32 outType; if (message->FindInt32(kTranslatorField, reinterpret_cast<int32 *>(&outTemp)) != B_OK || message->FindInt32(kTypeField, reinterpret_cast<int32 *>(&outType)) != B_OK) return; translator_id outTranslator = outTemp;
comment:14 by , 13 months ago
I can't provide a patch soon, but the fix looks trivial, I guess someone else could do that.
comment:15 by , 13 months ago
I can confirm the fix. Suggested patch: https://review.haiku-os.org/c/haiku/+/7102
comment:16 by , 12 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Fixed in hrev57380.
Is this a dup of #6777 ?