@sashapont: On Aranym or Hatari 256 colors resolution mode, it works OK on my side. Does it happen only on Firebee? Send me vision.log to see if I see something wrong (make sure to have LoggingFlags = 1ff933f in vision.ini before starting VISION). Are you using "Save as..."? Please describe more your issue.
JeanMars wrote:@eero: you're right, if it is a Falcon, AES popup usage is forced. However it is on purpose as regular Falcon AES version is 0x0330 and so VISION can't rely on appl_getinfo to know about popup features. I could remove this force but in this case, regular Falcon will lose AES popup support...
Code: Select all
TYPE : FALCON030
PROCESSOR : 68030
FREQUENCY : 16 MHz
TOS VERSION : 2.06
GEM VERSION : 0.20
AES VERSION : 1.40
JeanMars wrote:Can you point me to the exact emutos file you are using? I tried on Hatari and it looks OK.
JeanMars wrote:On Hatari, TOS 4.92 and ST-High resolution, help bubble display is correct (see attached picture); what is your configuration exactly?
JeanMars wrote:In 4colors resolution, I agree this is buggy but honestly I won't fix it, this is too an exotic resolution to spend time on it...
Eero Tamminen wrote:(Besides, AFAIK all TOS functions return the function number if TOS didn't recognize the function. I assume the same applies also to AES functions like appl_getinfo().
If you want test for appl_getinfo you can use this:
https://freemint.github.io/tos.hyp/en/a ... l_xgetinfo
JeanMars wrote:Problem with this routine is that it won't return support for a classic Falcon as AES is 3.30.
I have added test for AES version >= 3.30 if Falcon is detected.
Please test it at: http://vision.atari.org/download/temp/vision.zip
I also added a warning message for 4color modes.
when it encounters something unsupported, it seems to just send the file to the viewer, which is imho not what the user expects.
And another thing: the multitos drag&drop protocol does not seem to work. I'm seeing routines in vision which should handle it, but it does not work, i always get a timeout from the desktop when dragging something to visions windows. I'm not sure what header files you use, but you should be aware that the definitions SIGPIPE, SIG_IGN etc. from Pure-C headers are not the one MiNT expects, those are meant for Pure-C's signal() function, but not for Psignal().
JeanMars wrote:To me, it was just to open files when they are drag&drop to executable's icon.
JeanMars wrote:Hi Thorsten,
thanks for the log.
Actually dragdrop.c is part of TOOLS folder but it not listed in VISION.PRJ I have added this file some time ago with probably in mind the idea to use it at some point but I never did.
I don't see this issue on my side as I'm using Thing! desktop which uses a different protocol apparently when it comes to drag&drop to an application window (probably WM_VASTART (which is supported) but need to check).
I have to have a look at this protocol to see how I can implement it. At least I can add relevant code to report a negative acknowledgment (https://freemint.github.io/tos.hyp/en/p ... #ddlisting).
OL wrote:you can use this small library for dragdrop use.
ThorstenOtto wrote:OL wrote:you can use this small library for dragdrop use.
That's about the same he already has as source in the archive, but which is not active yet. And it has the same problem: it uses Pure-C's definitions of SIGPIPE and SIG_IGN, which is wrong for Psignal()
Users browsing this forum: No registered users and 6 guests