19 February 2022, 15:29 | #1 |
Registered User
Join Date: Apr 2018
Location: Wales, UK
Age: 41
Posts: 102
|
NewDTObject with JPEG datatype crash
Hello,
I having a strange issue with NewDTObject and the DTA_Handle tag item. When I do so, I get a #80000008 Guru when I do so. I would like to read a JPEG image within a file, but its not at the beginning. I am 100% certain where it seeks to is a valid JPEG header, and the BPTR is correct and seeked to the correct position. I have checked this file and location with a hex editor. I have also extracted the JPEG file via a hex editor and it loads fine. Loading another similar JPEG file via the name as a path works fine as well. This is my code (simplified): Code:
BPTR file = Open("some-file", MODE_OLDFILE); Seek(file, offset, OFFSET_BEGINNING); Object* dtObj = NewDTObject( NULL, DTA_SourceType, DTST_FILE, DTA_GroupID, GID_PICTURE, PDTA_Remap, TRUE, PDTA_Screen, (ULONG) mScreen, PDTA_DestMode, PMODE_V43, DTA_Handle, (ULONG) file, // << -------- This here. TAG_DONE ); I am on AmigaOS 3.2.1, with the default JPEG data type. If anyone can shed a light on this, It would be most appreciative. Thankyou, betajaen |
20 February 2022, 13:59 | #2 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
You should provide a compilable source to make it easier for people to help you. I spent quite some time now to construct a test from the information you provided, and I never worked with datatypes in AmigaOS before. It looks like this:
Code:
#include <exec/libraries.h> #include <dos/dos.h> #include <intuition/intuition.h> #include <datatypes/pictureclass.h> #include <proto/exec.h> #include <proto/dos.h> #include <proto/intuition.h> #include <proto/datatypes.h> struct Library *DataTypesBase; struct IntuitionBase *IntuitionBase; #define DTVERSION 43 int main(int argc,char *argv[]) { BPTR file; struct Screen *myscr; IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library", 37); if (IntuitionBase == NULL) return 20; if (DataTypesBase = OpenLibrary("datatypes.library", DTVERSION)) { if (argc>1 && (file = Open(argv[1],MODE_OLDFILE))) { if (myscr = OpenScreenTags(NULL, SA_Title, (ULONG)"Test", TAG_DONE)) { Object *dtobj = NewDTObject(NULL, DTA_SourceType, DTST_FILE, DTA_GroupID, GID_PICTURE, PDTA_Remap, TRUE, PDTA_Screen, (ULONG)myscr, PDTA_DestMode, PMODE_V43, DTA_Handle, (ULONG)file, TAG_DONE); Delay(50); if (dtobj) { Printf("dtobj = %08lx\n",(ULONG)dtobj); DisposeDTObject(dtobj); } else Printf("NewDTObject failed.\n"); CloseScreen(myscr); } Close(file); } else Printf("Cannot open file!\n"); CloseLibrary(DataTypesBase); } else { Printf("No datatypes V%ld!\n",DTVERSION); CloseLibrary((struct Library *)IntuitionBase); return 10; } CloseLibrary((struct Library *)IntuitionBase); return 0; } |
20 February 2022, 14:29 | #3 |
Registered User
Join Date: Apr 2018
Location: Wales, UK
Age: 41
Posts: 102
|
Hi Phx,
Thankyou for replying. Very sorry for not producing an example. I will do better next time. Anyway. I doubt this is a bug with datatypes.library; AmigaOS 3.2.1 and 3.9 are from different times. My only conclusion is that DTA_Handle cannot like used by that. Maybe its used to get the Handle (BPTR) of the datatype. Although the documentation suggests it can be used in the NewDTObject function, as an alternative to the name argument. For now; I have temporarily extracted the data from the original file, and wrote it to the RAM drive, and then open it that way - which works, but not ideal. I did experiment with the DTA_SourceType being DTST_MEMORY, and load in the data manually into RAM, but that did not work either (although no crash, just a NULL Object), may I did that one wrong though. Thankyou, betajaen |
20 February 2022, 20:18 | #4 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,496
|
Quote:
Code:
DTA_Handle - Can optionally be used instead of the name field. Must be a valid file lock if DTA_SourceType is DTST_FILE. Must be a valid IFFHandle if DTA_SourceType is DTST_CLIPBOARD. Will be ignored if DTA_SourceType is DTST_MEMORY. NOTE: If you provide a file lock if DTA_SourceType is DTST_FILE then this file lock will become associated with the data type object. Do not UnLock() it, or freeing the data type object will result in the same lock being unlocked again! If you provide a file lock on a file, you must also provide the name of the file or it will fail to open. This makes the use of the DTA_Handle difficult to justify for this use case. Lock()that file, not Open()it. Also don't UnLock(), because DisposeDTObject()does that for you. And you still have to specify the correct file name in the first argument! Worked for me. No more crash. Although I'm not sure how useful this feature is. |
|
20 February 2022, 21:01 | #5 |
Registered User
Join Date: Apr 2018
Location: Wales, UK
Age: 41
Posts: 102
|
That's the documentation I was following. I must of confused DTST_File with a BPTR from Open, rather than from a Lock.
So it seems its not possible for it to directly load a file within the middle of another file after all. That is disappointing. Thankyou for your help! |
21 February 2022, 11:34 | #6 | |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
Quote:
I guess the same is true for DTST_FILE with DTA_Handle. Furthermore all documentation is worth nothing if the datatypes sub class does not support it. Reading data is not done in a central place but in the sub class code. You cannot trust every sub class author to implement all methods to read data. So if your code is public you should consider that the user can have installed replacement datatypes which do not support the less famous variations. Finally reading part of a file which is not in the beginning of the file is a very special case of another special case. I would expect that to work only by chance if at all. |
|
22 February 2022, 07:04 | #7 |
Registered User
Join Date: Apr 2018
Location: Wales, UK
Age: 41
Posts: 102
|
Hi Thomas,
Thankyou for filling the gaps. You right being this special case, but I am trying to read in files within an uncompressed archive. Essentially, 1000s of JPEGs in a custom file format (with other application specific information). I hoped not to extract them into separate files, but this looks likely to be the case now. Thankyou both for your help and insight. |
22 February 2022, 12:35 | #8 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 6,985
|
If you know that the file format is always JPEG you could use jpeg.library instead of datatypes. IIRC jpeg.library has callback hooks for reading data, so you could get the data from wherever it is.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Using JPEG with Amos | WAKD | support.Apps | 25 | 21 January 2021 07:57 |
which picture.datatype? | Bamiga2002 | support.Apps | 29 | 25 October 2018 04:41 |
AROS: ico.datatype and info.datatype | AMIGASYSTEM | News | 0 | 17 October 2018 08:53 |
JFIF (JPEG) picture datatype 44.9 | HanSolo | support.Apps | 8 | 01 September 2018 12:38 |
NewDTObject crash | tolkien | Coders. System | 5 | 06 April 2015 14:22 |
|
|