Welcome, Guest. Please login or register.

Author Topic: Layers.library V45 on the aminet  (Read 64630 times)

Description:

0 Members and 1 Guest are viewing this topic.

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #389 from previous page: September 21, 2017, 09:19:27 PM »
Quote from: TuKo;830796
Would that fit ?

I wouldn't know where to fit the card in. (-:

Frankly, I'm trying a bit harder now to reproduce this on a clean system. In an attempt to make this simple, I wrote a small arexx program that moves a window over the clock:
Code: [Select]
/* move window test */
call addlib("rexxsupport.library",0,-30)
address WORKBENCH
do i=1 to 50
 do j=1 to 5
  movewindow window "SCSI:" leftedge 500-i*5+j*2 topedge 10+i-j
  call delay(1)
 end
end
which mimics a bit the erratic pattern in which a window overlays the clock. But without much success.  You may try to play with this as well, adjusing coordinate names and window names, of course.

I need something that is a little bit more reproducable than just moving the mouse by hand, and something that is a little bit more reliable than MCP.

The problem here is that one cannot reliably call MoveWindow() from within the intuition input handler (which is responsible for the dragging the window, receiving the move movements and performing the actual layer movement as well, actually). My best guess is that MCP plays with the rather delicate semaphore hierarchy of intuition to avoid a deadlock, but then fails to cover the interactions between all the semaphores correctly, leaving some structures unlocked that should rather be locked, hence causing a conflict somewhere.

If there would be some other form of moving the window *but* MCP, then I would have second look, but this particular program is so much known for its bug riddance and ignorance of system guidelines that I don't really want to make any speculations as where to look.
 

Offline Georg

  • Jr. Member
  • **
  • Join Date: Feb 2002
  • Posts: 90
    • Show only replies by Georg
Re: Layers.library V45 on the aminet
« Reply #390 on: September 22, 2017, 08:47:15 AM »
Quote from: Thomas Richter;830890

The problem here is that one cannot reliably call MoveWindow() from within the intuition input handler (which is responsible for the dragging the window, receiving the move movements and performing the actual layer movement as well, actually). My best guess is that MCP plays with the rather delicate semaphore hierarchy of intuition to avoid a deadlock, but then fails to cover the interactions between all the semaphores correctly, leaving some structures unlocked that should rather be locked, hence causing a conflict somewhere.


Intuition executes MoveWindow() asynchronously, so there are not many semaphores involved. But as said solid window moving commodities/tools (there are others like MultiCX) would typically call MoveWindow() from a helper task (or the main task), as otherwise while quickly dragging windows around there is no time for low pri app tasks to refresh simple refresh windows (until user stops dragging window for a moment) and you get a DPaint like brush-paint effect. Unless other hacks are used to for example force all windows to be smart refresh.
 

Offline Georg

  • Jr. Member
  • **
  • Join Date: Feb 2002
  • Posts: 90
    • Show only replies by Georg
Re: Layers.library V45 on the aminet
« Reply #391 on: September 22, 2017, 08:50:53 AM »
As for the ARexx script: if possible (and if you don't trust other tools) make it loop forever and move window to screen mouse coords and remove delay.
 

guest11527

  • Guest
Re: Layers.library V45 on the aminet
« Reply #392 on: September 22, 2017, 10:58:27 AM »
Quote from: Georg;830900
As for the ARexx script: if possible (and if you don't trust other tools) make it loop forever and move window to screen mouse coords and remove delay.
This doesn't make any difference. As you say, MoveWindow is asynchron. It essentially builds up a message, and pools it up in the input queue of the intuition input handler. The input handler runs once per VBI, thus any attempt to run the window movement more often just pools up more messages, but does not create more work.

The problem here is, however, the interaction of the calling task through messages with the input handler. Thus, if you call MoveWindow from *within* the input handler, this might have undesireable side effects.
 

Offline TuKo

  • Jr. Member
  • **
  • Join Date: Sep 2013
  • Posts: 69
    • Show only replies by TuKo
Re: Layers.library V45 on the aminet
« Reply #393 on: October 05, 2017, 04:18:59 PM »
Thomas, I tried the ARexx script and unfortunately it didn't trigger the bug. It seems to me bug is triggered when switching focus from one window to another.
« Last Edit: October 05, 2017, 04:22:50 PM by TuKo »