HostPorts.Input fixup

All except GUI problems

HostPorts.Input fixup

Postby luowy » Sat Oct 16, 2021 1:14 am

Recently, BB became unstable after win10 automatic update, especially during Drag&Drop mouse operations,
e.g. Alt + Drag to pull attributes, BB will lose respond... After applying the following patch, My BB is working again.
Code: Select all
   PROCEDURE (rd: Rider) Input* (OUT x, y: INTEGER; OUT modifiers: SET; OUT isDown: BOOLEAN); 
      VAR msg: WinApi.MSG; wnd, mw: WinApi.HANDLE; pt: WinApi.POINT; res: INTEGER; set: SET;
   BEGIN
      wnd := rd.port.wnd;          
      mw := WinApi.GetCapture(); 
      (*res := WinApi.UpdateWindow(wnd);*)  (* optional, side effect maybe *)
      IF WinApi.PeekMessageW(msg, mw, WinApi.WM_MOUSEFIRST, WinApi.WM_MOUSELAST, 1) # 0 THEN
         mx := (msg.lParam + 32768) MOD 65536 - 32768; 
         my := msg.lParam DIV 65536;                  
         IF (mw # 0) & (wnd # mw) THEN
            pt.x := mx; pt.y := my; res := WinApi.ClientToScreen(mw, pt);
            res := WinApi.ScreenToClient(wnd, pt);
            mx := pt.x;
            my := pt.y
         END;
         mb := {};
         set := BITS(msg.wParam);
         IF WinApi.MK_LBUTTON * set # {} THEN INCL(mb, left) END;
         IF WinApi.MK_MBUTTON * set # {} THEN INCL(mb, middle) END;
         IF WinApi.MK_RBUTTON * set # {} THEN INCL(mb, right) END;
         
         IF WinApi.MK_CONTROL * set # {} THEN INCL(mb, ctrl) END;
         IF WinApi.MK_SHIFT * set # {} THEN INCL(mb, shift) END;
         IF WinApi.GetAsyncKeyState(12H) < 0 THEN INCL(mb, alt) END; 
      ELSIF  (WinApi.PeekMessageW(msg, 0, WinApi.WM_TIMER, WinApi.WM_TIMER, 1) # 0)  THEN
         res := WinApi.DispatchMessageW(msg)
      END;
      
      IF WinApi.GetSystemMetrics(WinApi.SM_SWAPBUTTON) # 0 THEN
         IF WinApi.GetAsyncKeyState(WinApi.VK_LBUTTON(*1*)) >= 0 THEN EXCL(mb, right) END;
         IF WinApi.GetAsyncKeyState(WinApi.VK_RBUTTON(*2*)) >= 0 THEN EXCL(mb, left) END
      ELSE
         IF WinApi.GetAsyncKeyState(WinApi.VK_LBUTTON(*1*)) >= 0 THEN EXCL(mb, left) END;
         IF WinApi.GetAsyncKeyState(WinApi.VK_RBUTTON(*2*)) >= 0 THEN EXCL(mb, right) END
      END;
      IF WinApi.GetAsyncKeyState(WinApi.VK_MBUTTON(*4*)) >= 0 THEN EXCL(mb, middle) END;
      
      IF WinApi.GetAsyncKeyState(WinApi.VK_SHIFT) < 0 THEN mb := mb + {shift, extend} ELSE mb := mb - {shift, extend} END;
      IF WinApi.GetAsyncKeyState(WinApi.VK_CONTROL) < 0 THEN mb := mb + {ctrl, modify} ELSE mb := mb - {ctrl, modify}END;
      IF WinApi.GetAsyncKeyState(WinApi.VK_MENU) < 0 THEN INCL(mb, alt) ELSE EXCL(mb, alt) END;
      x := mx; y := my; modifiers := mb; isDown := mb * {left, middle, right} # {};
      WinApi.Sleep(1);
   END Input;
luowy
 
Posts: 83
Joined: Thu Dec 17, 2015 1:32 pm

Re: HostPorts.Input fixup

Postby Ivan Denisov » Thu Oct 28, 2021 5:50 pm

This code is different in many places. Can you say, please, which is the patched line?
User avatar
Ivan Denisov
 
Posts: 340
Joined: Tue Sep 17, 2013 12:21 am
Location: Krasnoyarsk, Russia

Re: HostPorts.Input fixup

Postby luowy » Fri Oct 29, 2021 1:14 am

They are all workable,the last one is the best one, i think;
the first one(community) is emergency patch, to solve the problems caused by win10 update,
The second and third (center board) are gradually improved:
1, the "idle" varible introduced to avoid sleeping after a Services.Action
2. "serverMode" gives Services.Action a higher priority, avoid the adverse effects of mouse movements
3, Add "isDown" as a sleep condition, quickly exit the "until loop" ;


the final version is:
Code: Select all
StdCoder.Decode ..,, ..97,...3QwdONl9RhOO9vRbf9b8R7fJHPNGomCrlAyIhgs,CbKBhZ
 xi2,CoruKu4qouqm8rtuGfa4.hOO9vRb1Y66wb8RTfQ9vQRtIdvPZHWKqtCa.E.U5UMD06.5Qw
 dONlnayKmKKqCLLCJuGqayKm6F9vQ5nsH3.bnayKmKa2,Cor.kay4.qorGqmQCU2,CJuyKtQC9
 8P9PP7ONbXmb.2.ApDk5kEz.,6.,.1j.cU.ktAcoZimBhWhiohgnZcZRC.,.D,0.p.,6.oD6.J
 Fyuv.U.2m,.1.1cUZj0E.s7E.c4E.k.0.,c8.2UE0O,8E,9T3E.0.D,0.p.0EKF.EJ.6.th.k0
 k,8Mtf.2.m00.e,2.A.2Ue.E.m9M.M.z,7cUZj0E.696.c4E.2k.F.c8.0E.07M.,U,Y9gU0Ky
 8.,UcV.UO.,kmqA0E.e0.,6YUFU,A2YU,U,w1.23gUB.1,9sWM.R,5M1M.3.C,A6oU0Ky8U.2.
 y70E.c4E.2E2.e0M.6YE.8E.M.Di.QUBU,I.Q.M.10Bc.M.Jg.YU1.1.9MT6,k.G,OkGUWF.CE
 3E0KE.EXk,U2.i2C..g6Q.s,3gwJ.,6..EBU.6U6.I3l6w1.,6.V2I.YU,U5I.AU9,k1U2.U,I
 7QU6U,wBc0M.N15s,M.5I.gUJ2.4k6k0C.4k4kzbEc8pbCoWGoe8pW0GI8LmeHE8poGqm8rI0m
 YuKsKLueGEWmbKJe0GwmGEaLR0mYuIeKoXKIdiHEyoeGZhxhYBhaBhZJinJbUQe3Zev2YDh8aq
 tGorSLreHE8obyIaKoUuoIiHE0m4ak2OpU8JEqqtSKR0mfaKr4IsaKLqodSoR0mvuKmmGEqqve
 HES3EY4IbGIaKoR0GsGLR0mfa46ITOGR8Jr76ZPNbfC,NGR0ktKKueHECpWM1HM0h0H9NNPNpd
 ETuHN0rN1HcE9uFHeHPM0HsRR9N,dCv76Z9NR7QTfQdf9jfP7vC,N0HM0,N1HM0PvR,dCv76jO
 OR1SomGrV4KsGru8rmWmIiHE0GEqk22ZeIiZRiUIbx.ke0Lm4KuKqfaKrGqrSLISLrGqIiHJaG
 EaKmmaUIbx2YIJeJhcvgV7AV7pcUYcdBggxhbpZnhgmpiZJiBxhYhgUYe6hcC3YBAV7AV7FEWm
 faKrUEhgZRhBhgnRiVxgZxecghnxgg2YkYZUwedpBsJPuLdOGPOFZ89,tJH1..XN8,t6,7AH76
 ,7JFOF.HMO79P9fCvdF18HbOFrN1Hk2aEtKqt00S3EWaqt0rkGrlWqaKqtC5.H,gcARe7pcUwe
 d,03..mWhxig2YLBBkfMHTOJbOFBOGZuId89,tJ..Yd,ReIZZUAad.,7J.AVh3jUIbx68PvQDf
 9N9I1fQ1PP,t8,tAZtBh7CH76PuH786hNBftAh76P76bdAjVv2YUg,AVhBjUIbxMPbvN.Yc7pe
 Uoapg4in2ak2ak22YU2YBU7A7WmqSLECGE0nIoYU2ZrphY3YX2Yhxid2YI37qk2AV76Qdf9l96
 pND2jv2YkZiiAjUIbxkwiHE8rm22w8U1ZhdhgiZiIxhHRgmhgZphcghrZ3V9RHtCPM0A,Z1.kd
 CKtK4duP58PHPN2ZrpBNFsG5,N1HM0aUh3D6Qdf9lvC,N1HU7MPn1kwqk2ak2akWuIWin4k2qK
 l0GRqHEiryin4a.HsQ99R,dCIc7ZeH3ZhRCSLc4Kt4adQbBA,akYOYL,gd9xfAJcJZeIxdC3Ye
 2Ynhgo3YXsSv96d8G2Y7pd1ZdcghWZZUYhZpgoBZUgcCZcv.HMG..PeEf8Jd0....qqoGKmmqm
 aGEKIb.akY..8JVKJeG3....IidxgcZid2Y3,M0PM0Hk2aIX..5uHR8JZuHN86J76b1...CKu8
 LqaGEK2U7A7.UH3d7pcI3Ye22...ktWqoOKua0.akY.kXMEbPSRvMLONnvIdPMdHI4HNWoI0GS
 0GM0Ge..AggZid2266,,0mWu2HM0PM0HMFNmWqk2ak2aIX.6I..PXg.S3kf.o6UL,.Ea.X,22k
 4k2qKwUcUiYBEEi0kI.UUkNUv66k2qqw00qqt.EW.sCk22YU.akY68.H,EEMP.q.aUkVU.l166
 kw.kfoBsEUI,68Esk4k2IC..b0Y8.F,NFsEEU7MPl105lvCq.aUhBD.nP1aU7gcCl4k2qKlUv,
 AVnVuEV.sRUd.akYOYL,g7m2.UXsSY82Y7p7.N1.k2a2.ka.....MP..M0H0.cI.....IC..ak
 4A,HMGB0.Q6.J,...sM..akY..C3....kt..M0H0.D0...24..AA.00MFNmY66.28.UhFK24.w
 8GZBVUw8..MA.00M1M0Z1sJ.70..kIg,gcCl4MF.Pk2WWUQgchgXRhU2YhxhpRiZ3YWhioZijp
 hUAhn3YmhgghgVRiZZgUM8PM0HMGB0U5ldartGrmqqaKKu8roCqtWmfaKrUHhdTReLBcEJcJZ8
 AZUQYU66k4kY.kXME..Spou4oe9xfAJ6EIemMemIaGEunS0GM0GeEEKIgCIaWmqEt..A,.sF..
 .UKFd82UmIZdAZU...6P.gV7AV3Z79W7A,.sF...UKFa.MA.....Q5..S2...cJI8.81...cQ.
 M1cHU7,U5,...O3PeE.GHJamI00..Uh,.r76PUBM0HeF.w6...EfsIF0H76t,UhJgUI5qKl0mJ
 0mxCLoaKnYZUggsZiZphYhjUgcARe33YhJAp,gZUQjn3B..u2P..sF...UKlVy2M8,7D.Uu.i0
 59RZ9PN76PvP7POary0mWm2ER.PVXZC.kWuIW..sF...UKlaKIbKpI0GS00U7,kkU3Z7gcMR6.
 UC,WLEe1W5n96pNDADqqrG4H1,dCvVWRbUAhnZ62Yug52Ye2YvZhZpgoZ3PPOEK0Gta4qLECGE
 ibvU7loG4,d7,NOb9FEeWoWsJH1umdmqmKKsWmMamRKIbGo4gcC76HePVHuiHE8ssH3CoruKu8
 rrmKqKKtCLLCJuQcoJigZcZRiX3Ulb8..umVyKrG5EWKqtCK.Q6AAICUm,..Unp3.6F6.Z50.G
 ,,6.M00U.2..AU0CyIhA8pumqm8rtumdcIf9PY62Ulb8.CLL8pumqmY62UmTU.E.0.L3D6.QI2
 U.sU.ktumdsIdPSNPN7ONbH.4D.o3aLq.,cwFE.2..FE.I90E.0.32.oZ,ZCUZ7F6.G.0..676
 .16.6.665hK2.,6TxR.Wnl2UsQA4.2.8Mtf.2..c4E.k.Ue2UwV.E.0t.U...ve1...
 --- end of encoding ---
luowy
 
Posts: 83
Joined: Thu Dec 17, 2015 1:32 pm

Re: HostPorts.Input fixup

Postby adimetrius » Fri Nov 05, 2021 10:31 pm

Some questions:

1. Here https://community.blackboxframework.org/viewtopic.php?f=48&t=181&hilit=ghosting was a brief discussion of window ghosting, whereby Josef suggested removing all messages from the WinApi queue while only processing mouse messages by using 0, 0 for filters in the call to PeekMessageW. Your suggestion reintroduces filtering, and allows the timer messages to be processed thru DispatchMessage. I wonder if the BB@Win10 malfunction could be caused by exactly that - the timer message not being timely processed? Because if it were due to any other message, Input would be stuck with that message forever:

Let's say WM_SOMETHING were posted to the WinApi queue. PeekMessage would not return it, because of the filters set to mouse messages and timer messages. This would leave OUT isDown unchanged, which in a conventional mouse tracking loop REPEAT ... f.Input(...isDown) UNTIL ~isDown would cause endless repetition. This could be helped by an unconditional mb := {} in the beginning of Input; this way, the loop would end. HOWEVER! It would not be true: WM_SOMETHING would always result in isDown = FALSE, which is wrong (false).

2. Retrieving WM_TIMER with PeekMessage and then processing it with DispatchMessage essentially results in Services.actionHook.Step - background task processing. Is this correct? The upside of this solution is keeping WM_TIMER messages in balance with calls for Services.actionHook.Step; the downside would be that it makes the call for Services.actionHook.Step more obscure: WinPorts.Rider.Input -> DispatchMessage -> HostMenus.ApplWinHandler -> Kernel.Try(HostMenus.TimerTick) -> HostWindows.Idle -> Services.actionHook.Step. This is buried deeeeep.
(Actually, it is guarded in HostMenus as follows: IF ~HostCFrames.inHandleMouse THEN HostWindows.Idle END, so if the mouse were pressed inside a host control, background tasks would not be executed, and Josef's server would block again.)
Maybe it would be beneficial to skip WM_TIMER messages (PeekMessage them, but not DispatchMessage them) and call background actions explicitly, as in the current edition? Maybe purging WM_TIMER from the WinApi queue would keep Windows happy... I don't have Win10, so can't set up an experiment.

3. I have ran into a problem with the current edition of Input. In response to a PollCursorMsg, I need to force view redrawal (to draw background for a menu item the mose is hovering over); this is an expensive operation, and it results in some lagging: while the redrawing is done, more WM_MOUSEMOVE are posted, then translated into more PollCursorMsg. So, after a while msg.x is not where the mouse is actually at the time PollCursorMsg is handled by my view. I call f.Input in order to use actual mouse coordinates and avoid unnecessary redrawals.
Well, the way Input is implemented now, it purges the queue of WM_LBUTTONDOWN! This means that (sometimes) after PollCursorMsg the TrackMsg is never sent, because f.Input has processed WM_LBUTTONDOWN, and WM_LBUTTONDOWN is not delivered to HostWindows.DocWinHandler, which translates it into a TrackMsg. To the user, this means some clicks never click. Very annoying.

From reading the docu for Ports, it seems to me that this should be considered a bug: Input is not supposed to interfere with subsequent TrackMsg, and there are no restrictions on when Input may or may not be called. Don't have a solution to this yet.
User avatar
adimetrius
 
Posts: 64
Joined: Sun Aug 04, 2019 1:02 pm

Re: HostPorts.Input fixup

Postby adimetrius » Sat Nov 06, 2021 5:50 pm

Update for p. 3 of my last post: the lagging I described only occurs in Linux. Turns out in Windows WM_MOSEMOVE events never 'stack up' in the queue, and the WM_MOUSEMOVE message always contains the most recent pointer location. However, f.Input still 'eats' WM_LBUTTONDOWN messages and thus a corresponding TrackMsg; which is a malfunction. I was able to work around it, though, by patching the Linux's Rider.Input and 'window procedure' so that they always deliver the most recent pointer location in PollCursorMsg and in f.Input; and thus eliminating the need for an extra call to f.Input for the most recent pointer location. So the bug is dormant for now, again after a one-week awakening )
User avatar
adimetrius
 
Posts: 64
Joined: Sun Aug 04, 2019 1:02 pm


Return to BlackBox Framework

Who is online

Users browsing this forum: No registered users and 1 guest

cron