DTM_WRITE feature requests

[ssolie]

Yes, I wanted to be able to convert Datatype pictures from one format to another for a personal project, a little picture viewer, FastView.

We'll try and release them but there are some non-technical issues to resolve first.

[zzd10h]

Many thanks (by advance) !

[zzd10h]

@salass0

Thank you for the release of DTConvert on OS4Depot.

[salass00]

@salass0

Thank you for the release of DTConvert on OS4Depot.

You're welcome

[zzd10h]

Hi,
since Update 1, it seems that DTConvert/main.c

dst_dt = IDataTypes->NewDTObject(NULL,
DTA_SourceType, DTST_RAM,
DTA_BaseName, base_name,
PDTA_DestMode, PMODE_V43,
TAG_END);

failed, at least for picture type.

Could it be related to this change ?

datatypes.library 54.7
FIXED
o Using DTST_MEMORY objects could lead to a crash;
o SaveDTObject() in conjunction with DTST_RAM did not create
correct icons;

But after update 1 installation, my SYS:Libs/datatypes.library is 54.6 (08/01/2016) and NOT 54.7.
Typo error or not the correct one shipped ?


edit : Reverted to datatypes.library 53.4 (FE update 0) makes it work again.




Thanks

[salass00]

Yes, it does look like the wrong version was included in the update.

Versions 54.4 to 54.6 had a bug in the DTST_RAM handling but this was fixed in version 54.7 which was supposed to be the version shipped with 4.1 FE update 1.

[zzd10h]

Thank you for your reply.

Therefore, If I understand well, the v54.7 still works with DST_RAM ?
As I use DST_RAM in my FastView program, I just have to wait for an AmiUpdate delivery ?

Right ?

thx

[xenic]

Thank you for your reply.

Therefore, If I understand well, the v54.7 still works with DST_RAM ?
As I use DST_RAM in my FastView program, I just have to wait for an AmiUpdate delivery ?

Right ?

Hope so too. The bug fix turaround was so much faster with AmiUpdate releases than the 2 year wait for update1.

[zzd10h]

@Salass00
Thanks for the clarifications

[kas1e]

@zz10dh,xenic
Sadly , but that will not be amiupated, you probably have to wait another update