I mouseover some other player in grid.
  I cast Holy Shock.
  Here comes the strange part.
- If I move my moouse out of grid, and I move it back in directly on a player that is dead, it will do nothing when I press holy shock.
+ If I move my mouse out of grid, and I move it back in directly on a player that is dead, it will do nothing when I press holy shock.
  If I move my mouse over a player that is not dead, and after that I mouseover directly on the player that is dead, the heal will go to my selected target.
  In the moment I cast holy shock, my mouse is over the same dead player. Since I mouseover a player frame, I assume that is Clique handling the player. For some reason, Clique decides that the dead player is not a valid frame, therefore passes the action to bindpad. But this is different every single try, depending on the state of the player that I targetted before.

You must login to post a comment. Don't have an account? Register to get one!

• 

  • Reply
  • #21

  cerbul May 17, 2011 at 15:47 UTC - 0 likes

  LOVELY ! I commented the lines you said and works exactly how I expected it to work, awesome ! Thank You very much, and I really hope that future Clique updates will allow for this feature to be easily modified. Cheers!

• 

  • Reply
  • #20

  cerbul May 17, 2011 at 11:38 UTC - 0 likes

  "This is what *should* be happening when you move the mouse from A to B, but it cannot because of the way all of this is detected by the client." This carifies it for me good enough, and thank you for the time you put into explaining.

  I will post the results of the code comments you adviced me to add, in the evening, after I get home from work. Cheers

• 

  • Reply
  • #19

  Cladhaire May 17, 2011 at 11:03 UTC - 0 likes

  @cerbul: Go

  I'm not frustrated with you, I am simply frustrated. This conversation has been riddled with misunderstandings and miscommunications. I can't expect you to understand all of the intricacies that I deal with on a daily basis, but at the same time my only recourse is to try and explain things to you. This is exactly why I try to avoid people troubleshooting my issues.. there are very few people on the planet that understand exactly what is happening and it's a non-trivial matter to bring someone fully up to speed on how things are forced to work due to the UI.

  I appreciate you being curious and seeking clarification to ensure I properly understand your issue, but I've told you that I do and I've demonstrated that over and over again. I've also tried to explain things and that's just gotten even more confusing.

  When I say "the mouseover unit code triggers" I am NOT talking about your macros. This has absolutely nothing to do with your macros. I am talking about Clique, I am talking about WoW and I am talking about the broader issue that is at fault here. The "mouseover unit code" that I am referring to is the code that runs in response to the state driver, which checks for the existence of the mouseover unit. This is perfectly consistent with what I have been saying. It does not matter who is getting healed, because I am telling you *why* you are seeing the behaviour that you are seeing.

  As for situation 2, you're incorrect in your understanding. Again, this has absolutely nothing to do with your macros, its just the way things work. When you move from the 3D world (where there is no mouseover unit) to the offline unit frame (which has no mouseover unit) then the 'MouseFocus' bindings are still active (and will continue to be so until you leave the frame). This is what *should* be happening when you move the mouse from A to B, but it cannot because of the way all of this is detected by the client.

  The code I have written is working as intended, but unfortunately that intent doesn't match the behaviour I actually want to happen and is most certainly not correct. Unfortunately, I'm not a magician and can't fix things that are outside of my control.
• 

  • Reply
  • #18

  cerbul May 17, 2011 at 10:35 UTC - 0 likes

  Please do not get me wrong. The work you are doing is totaly awesome, and I really appreciate everything you are working on. I wanted to leave it as you said, just to don't create an unpleasant situation where I come up with something new every single post I do, but for the sake of clarification I feel that I need to specify that there are a few things that I described yesterday using the macros you told me to make, and that do not match with the explaining you made in your last post.

  At situation 1) that you described in your post, you said that if I move my mouse from A to B, "The mouseover unit code triggers". That is not what I had last night. I was getting instead the "@target code triggered". I am absolutely sure I was getting my target player healed. (the player I previously selected as my target).

  At situation 2) that you described, "When you move the mouse from the world to B", I was getting the spell cast totaly canceled. You said: "you went from no unit to another area with no unit". Doesn't that mean that I should have the "@target" code enabled at this point, since it doesn't detect any mouseover unit?

  Again, I might understand wrong the things you said (sorry in that case), but if I did understand correctly the text "mouseover unit code triggers" means that I am correct and there is something else not working as intended. Thank You

• 

  • Reply
  • #17

  Cladhaire May 17, 2011 at 08:09 UTC - 0 likes

  For the absolutely last time, I will post what is happening.

  Clique activates any 'key-based' bindings when the mouse enters the frame. Lets' consider the situation you are having where frame A is you, and frame B is a member of your raid who is offline or out of the zone (as in the frame does not exist as far as the API is concerned).

  In the previous version of the code, *regardless* of how your mouse enters the frame, your bindings will be activated. When your mouse leaves the frame, the bindings will be deactivated. Stupidly simple. The problem is what happens when a frame is hidden or shown while your mouse is over it. If your mouse is over frame B and the composition of the raid/party changes, causing the frame to momentarily be hidden and then re-shown, the bindings will be 'stuck' until you move your mouse from the frame (and sometimes even afterwards depending on the particular sequence of widget events). This means that you can have moved your frame into the 3-D world and the bindings will still be active. There was already code to clear those 'dangling bindings' as soon as you enter another Clique-registered frame, but that means your bindings are stuck until then.

  There's pretty much *one* option for fixing that, and that's watching for the existence of the "mouseover" unit. So I register a state driver that watches for changes to the mouseover unit's existence. When the mouseover unit used to exist and now no longer does, and there is a frame for which we have bindings active, those bindings are cleared. This is a bit of a 'hack' fix, and doesn't address the other side of the issue (where frames appear rather than disappear) but it was an improvement.

  Now it turns out that a frame with an offline/out of zone member also triggers this. So what is happening is this:

  1. When you move the mouse from A to B, the bindings from A are deactivated due to the move leaving the frame. The bindings for A are activated due to the mouse entering the frame. The mouseover unit code triggers, seeing that B has no mouseover unit, and then clears the bindings for B. Don't believe me? Bind 'W' and see if you can move forward in this case. You can.
  2. When you move the mouse from the world to B, the bindings for B are activated. The mouseover unit check doesn't trigger because there was no change in mouseover unit, you went from no unit to another area with no unit. The bindings remain active and run properly. Don't believe me? Bind 'W' and see if you can move forward in this case. You can't, it will run the Clique binding instead.

  Until WoW is able to provide us with a general way to handle these sorts of OnEnter/OnLeave bindings, my hands are pretty much tied. The best I can do is give you an option, but unfortunately *no* behaviour is correct while this problem persists.

• 

  • Reply
  • #16

  Cladhaire May 17, 2011 at 07:55 UTC - 0 likes

  You aren't understanding how it works, and you don't need to. The problem you are experiencing is that the bindings are being cleared by the code I posted. Commenting it out prevents this from happening.

• 

  • Reply
  • #15

  cerbul May 17, 2011 at 07:09 UTC - 0 likes

  After some additional testing I noticed that if I have the raid frames close to eachother, and I make a fast movement from myself to the dead/offline player, the cast will go to my target. The only way I was able to get the behavior I wanted (spell canceled completely) was to move my mouse first out of any frame, and then to put it on the dead/offline player. Seems like the only thing that helps is to hover away from frames first, which is not happening during a fight to be honest.

  About the possible fix you just posted, I will have to get home to test it out. Just to make sure, shouldn't the keybinds reset completely when I move to a new frame, and not only when I go out of frame first? To me seems like this code will keep in mind the state of the frame, and I will always get a cast on my selected target, regardless of hovering out of raid frames or not. What I need is to have the spell not work at all (not even on selected target), if my mouse is over a dead/offline player.(I am not being patient at all as you see, sorry for trying to get a double confirmation on this :p )

• 

  • Reply
  • #14

  Cladhaire May 16, 2011 at 22:39 UTC - 0 likes

  Just an FYI, this isn't something that can be fixed very easily at all. What you can do is remove the following code and see if that works for you. Take line 59-67 and comment them out, i.e. make it look like this:

  --     self.header:SetAttribute("_onattributechanged", [[
  --         if name == "hasunit" then
  --             if value == "false" and danglingButton then
  --                 self:RunFor(danglingButton, self:GetAttribute("setup_onleave"))
  --                 danglingButton = nil
  --             end
  --         end
  --     ]])
  --     RegisterAttributeDriver(self.header, "hasunit", "[@mouseover, exists] true; false")
  

  You should see the behaviour you expect at this point because the bindings will not be auto-cleared when you move onto the dead unit.

• 

  • Reply
  • #13

  cerbul May 16, 2011 at 21:17 UTC - 0 likes

  Much appreciated, If you remember to post in here when they fix it, or if you give me an idea where to track those bugs on official forums, I would really appreciate it.

• 

  • Reply
  • #12

  Cladhaire May 16, 2011 at 21:12 UTC - 0 likes

  Unfortunately no more information is needed, as I said there's absolutely nothing I can do without a change in WoW. It's either we have an issue where bindings 'dangle' and people die as a result of it.

  If it was within my power to make it so you could play this way with these specific overlapping bindings, I would. Unfortunately, that's just not something I can do at the moment. I've pushed the information through the appropriate channels and will do everything I can to get it resolved.