Problems trying to output text to a simple window

[alkis]

No obvious bug in the segment of the source code you posted. From your description, the bug most probably exists in where you handle the window events and/or your shutdown code.

[chocsplease]

OK I've found out how to reproduce the crash consistently. It happens if you move or resize the window while its in the update code (win_write). What I don't know is how to prevent this. It looks like its some kind of race condition.

I seem to remember reading something about this on a web site but cannot remember where or if there was a solution.

I guess I'll have to stop the Amiga responding to messages while the window is updating? But how do I do that??

Anyone any ideas?

[mark_k]

You can use IDCMP_SIZEVERIFY or better, IDCMP_CHANGEWINDOW to be notified when the window is about to be resized or moved.

[chocsplease]

Originally Posted by mark_k

You can use IDCMP_SIZEVERIFY or better, IDCMP_CHANGEWINDOW to be notified when the window is about to be resized or moved.

Hi Many thanks for the reply and sorry its taken a while to get back.

I'm not sure I can use IDCMP_SIZEVERIFY as having read up on it there is a warning about using AmigaDos functions inside a routine that is called by SIZEVERIFY, or any of the verify functions as AmigDos could display a requester and wait for this while my code is waiting for dos, result - deadlock.

I'm asking for messages when the user switches floppy disks, which could result in the AmigaDos - you must replace disk foo in drive whatever requester.

I am using IDCMP_NEWSIZE, and will change this to IDCMP_CHANGEWINDOW, however I cannot find anything that will allow me to queue this message (like the verify functions do) so am wondering if I will still get my problem when the user resizes the window while it is still updating?

I thought about using modifyIDCMP and clearing the messages at the start of the update, but this will result in me loosing the disk change messages etc.

I've found the Forbid, Permit pair - would this solve the problem? It seems a bit heavy handed to stop all multitasking but the net does suggest that they will prevent the sort of race condition I am running into.

Anyone any thoughts?

Thanks in advance and sorry for such a long post.

[alkis]

I think it would help if you write up a minimum C source (fully compilable) that exhibits the problem.

[chocsplease]

Originally Posted by alkis

I think it would help if you write up a minimum C source (fully compilable) that exhibits the problem.

Hi and many thanks for the suggestion.

I have built a framework of code that runs the function(s) that crash, though I confess I do not know what you are referring to when you say it should be fully compatible. Compatible with what please? All kickstarts? All versions of AmigaDos? Sorry I am at a loss here.

Anyway the below pastebin link is to the code.

https://pastebin.com/45CRLU5W

I'm afraid its still almost 700 lines - though many are blank - despite being a framework.

I compile using gcc -s - lamiga - noixemul -O2.

Run in the shell with at least a 16 colour display.

The crash occurs if you change the window while it is updating, that is text is being generated in the shell/window. If you change the window outside this then there is no crash.

I'm stumped Forbid()/Permit() do not have any effect but the Amiga locks solid and I have to reset.

I just hope someone can see where I am going wrong.

Here's hoping anyway.

[alkis]

If you remove ALL printfs (just printf) from inside write_win() it doesn't lock up anymore (at least in my tests).

Can you please check if that fixes your problem?

PS: the word was compilable as "I can compile it and produce an executable to check"

[chocsplease]

Originally Posted by alkis

If you remove ALL printfs (just printf) from inside write_win() it doesn't lock up anymore (at least in my tests).

Can you please check if that fixes your problem?

PS: the word was compilable as "I can compile it and produce an executable to check"

Many thanks - I've had it still crash in the past - but randomly since it appears to depend on if you adjust the window while the the write win function is writing - I was adding the printfs partly to find out where it crashed, and partly to slow the function down, is there a way of doing this without using printfs?

Without the printfs the function runs so quickly that it is v hard to adjust the window while the code is inside write_win.

As for compilable, compatible -oops

[chocsplease]

Well that was unexpected.

For some reason the test code I have posted is not crashing with the printfs removed from the write_win function - I tried with Printfs and it still crashed. I'm baffled as to why but will back copy this code into the original and see what happens.

I am getting a glitch however.

Sometimes if you resize the window and it is updating the text will either overwrite the border, or not update in the whole window - there will be blank rectangles.

I'm guessing this is an update/region issue but not knowing enough about these I'm struggling to locate the problem.

I thought I could prevent the window from being resized during an update by setting mywindow->MaxHeight to the current height and mywindow->MaxWidth to the current width, however this is not working.

Is there any way of temporarily freezing a window's size once it has been opened?

[chocsplease]

Ok I think I've fixed it by adding called to WindowsLimits at the start of the update routine (setting the limits to the current window size) and at the end (setting them to the old values).

Testing looks like it works and I no-longer get the problems where the window has blank rectangles or the text goes over the borders.

Now all I need to do is figure out how to get scoll bars to work - which I will post a new thread for as it's a different subject.