I've been successful in reading Datatypes, specifically AmigaGuide DT with
> AddDTObject() to the window.
> Delay a bit and then RefreshDTObjectA().
The "Delay a bit" part of it does not seem so great, but without the delay the Refresh doesn't take and the system is likely to freeze Intuition.
Delaying 1 second seems to be enuf, but there must be a deterministic way to determine when the object is ready.
Any info?
Thanks,
Tom
AddDTObject()
WaitTOF()
RefreshDTObject()
something like that? or does it need a longer delay between the initial creation and refresh?
as there is only "graphics.library/WaitTOF()" for 1/[PAL:50/NTSC:60] graphical delay
or "dos.library/delay(ULONG N)" where a count of at least 1 full second is required.
Hope this helps... or has another delay facility been added in the 4th OS release?
@Belxjander
The question is not how to implement the delay but rather, why it is needed at all and, especially, why Intuition should crash here if the delay is not long enough. The correct behaviour would be different: if there's a real need to postpone refreshing the DT object, it's Intuition that should call a wait internally, not the programmer.
AddDTObject()
WaitTOF()
RefreshDTObject()
Don't use WaitTOF() for general delays. The purpose of WaitTOF() is to sync graphic updates to the vertical blanking period so you don't flickering or tearing issues as you might get otherwise. Also if for some reason vblank interrupts are disabled or unsupported WaitTOF() will use a polling loop which I would think defeats the purpose of having a delay here in the first place.
hrmmm...
what was the Kickstart release 2/release 3 issue with ObtainGIRPort ?
there were several patches for that to be fixed in the original ROMs...
is there an equivalent patch for the 4th release system or even need of that?
it is something to do with Intuitions use of layers...
my memory is tickled about that... but I don't remember the specifics.
that is the only thing that comes to mind for me due to BOOPSI notes about ObtainGIRPort
and other limitations in graphics.library/layers.library calls and related locking.
I think I've got a correct procedure now. I was able to find a Tutorial by David Junod in the 3.1 SDK. (Considering that's gone now, and it does not look as if any system work has been done on them in a long while, I wonder if DataTypes should be considered "deprecated"?)
At any rate, your application can find out when a refresh is appropriate by using the Boopsi ICATarget attribute with the ICTargetIDCMP value. This causes the datatype (gadget) to send an IDCMP_IDCMPUpdate IntuiMessage to the window port on certain status changes. That message carries a pointer to one or more attributes and if DTA_Sync is in that list with a value of 1 then the datatype object is ready for refresh.
You get one of these on attaching the datatype object to your window, and also a stream of them when the window is resized.
Tom
@tbreeden
it does not look as if any system work has been done on them in a long while, I wonder if DataTypes should be considered "deprecated"?
Datatypes are, for instance, not designed for streamed data - this limitation will get back on us in the future (MorphOS has already solved that in their Reggae). Also, most of the current datatype development is focused on image classes while we still lack "official" OS4 superclasses for other types of data - videos, formatted text or structured documents (such as DocBook). But this is a discussion for the Hyperion forums, sorry for being off-topic here.
