Forum rules
Please read the forum rulesbefore posting for the first time.The more information you can provide, the quicker and more accurately someone can help.
NOTE: To reduce spam, new users can not post links or images until they have at least 4 posts.

I tested it at home both in CC2019 where unexpectedly it worked. I then tried it in CS6 I got as well and it worked too. Normally I don't use XMBC at home to anything, so I had to create Ps profile where I bound to 'middle button' F2 in 'button held' mode, so like in work. I also made sure it's Beta 15.

Then I downloaded settings I use at work, the same I sent to you and found it doesn't work. So it seems there is something in options of XMBC that I needed at work to be set that makes problem with Beta 15. For now I have no idea what is that and if I'll find it will be that something I need to be set the way it is.

I'll try to uncheck boxes and scroll values to see what that was. Then we can know is that something I can work without or it is something that should not be on, while Beta 15 fixed. Till then, thx for your time...

EDIT:

I compared settings from home computer and work station and found nothing I change makes difference. Then I deleted one of profiles I kept on profiles list, that I named 'Screen'. Finally everything worked like before.

The reason why it didn't was that 'Screen' profile was targeted to same process, photoshop.exe, but the other Parent Class. 'Plótno' was to 'Window', while 'Screen' to 'OWL Document', that I needed for work in Full Screen Mode. Yes, for some reason when that mode is set then Parent Class changes.

What's good that remained from some kind of work I don't use anymore. At least I think so. I don't know yet whether is somehow useful for that I do right now. Temporarily I unchecked this process.

Conclusion: there may be problem with new Beta in case someone like me wanted (not currently though) work in Photoshop with XMBC in normal and full screen mode. If so, the new Beta would block main Ps process in full screen mode but allowed only full screen mode photoshop process.

Till now that was like 'Plótno' worked together in normal and full screen mode, while 'Screen' worked only in full screen mode. That was good for me, as I didn't have to move many simkeys commands from 'Screen' profile to 'Plótno' profile.

Is there chance for option in settings that we can decide we want the way how XMBC works in this specific case, so like before / after Beta 15?

Summing up:

Beta 14: if there is photoshop.exe (Plótno) process it works for everything, but if there is 'subclass' (Screen) then photoshop.exe still works for everything while that 'subclass' only when this class is active.

Beta 15: the difference is photoshop.exe (Plótno) doesn't work when subclass of Photoshop.exe is active.

Aha... yes got it...
In Screen, you have specified a parent class and then ticked the box "only if there is no parent class" which seems odd - how can there be no parent class AND the parent class be "OWL.Document"... So I have probably broken (or changed without meaning to) the "only match if there is no parent class" option - I'll have a look to see if I have really broken it or fixed something that has been broken for ages (i.e. fixed something that you just happened to be benefiting from). It may be as simple as un-ticking the "Only match if there is no parent class" in the "screen" profile?

I also notice (whilst it probably does not matter in this case except to needlessly reduce performance (regex is more CPU intensive)) that the screen profile uses regular expression checking but then there are no regular expressions in the search fields - this is a potential problem because in regex, photoshop.exe WILL match but only by accident. In regex, the character '.' is a wildcard that means "match any character" so it will match photoshop.exe but also it will match photshowyexe and photoshop$exe and so on! Same with OWL.Document, it will also match OWLYDocument, OWL-document, OWLcDocument and so on...

It triggers 'Levels' palette to adjust colors in the open image. When I hover it and I use mouse buttons with asigned simkeys everything I do in Beta 14 works as should. When I'm hovering outside of this palette, then 'Levels' profile doesn't work of course. The main photoshop.exe starts works (if some button is assigned by XMBC), what is correct. The main process photoshop.exe also works when I'm hovering 'Levels' Palette until 'Levels' profile use the same buttons but with other simkeys. That was very convinient.

In Beta 15 when I'm hovering 'Levels' it works like in Beta 14. If I don't have some button assigned by XMBC, but it is assigned in main photoshop.exe then in contrary to Beta 14 it doesn't work. Main photoshop.exe process / profile also doesn't work in Beta 15 when I'm hovering outside of 'Levels' palette (that's bad).

I don't have any problem regarding 'Levels' profile. Fortunatelly that was meant to work only within 'Levels' palette, so I don't need to hover outside it for anything else. but in case of 'Screen' profile that worked in Beta 14 in Full Screen mode it's problem as in this mode I used also main photoshop.exe profile / process (that I didn't want to rewrite from main photoshop.exe process - plótno - to that sublcass, so 'Screen').

I understand that behaviour of how it worked for years could be incorrect, as main process of application should be blocked while sublass window is up. Anyway I do think that is big limitation, and before Beta 15 possibility to use main process outside of subclass window or even within subclass window while there's not any XMBC action assigned to mouse button, but assigned to main photoshop.exe profile / process gave us wider scope of that we can do.

I think then, however I understand somone may wish the main process of one application was blocked when subclass window is open (at least to avoid some mistakes) this is also important to have chance to keep old behavioiur, maybe by settings checkbox, or better certain process options checkbox, since that second idea could let us block main processes for some applications while have them enabled for others we want they were fully accessible.

Good idea, but it did not change anything. Anyway that would be great to adjust hierarchy of processes by placing them in a tree of profiles. So if someone wanted main process worked over others so like in Beta 14 then easily could put it over others, and if not, so like in Beta 15 then under some subclass profile! Phil ???

XMBC stops at the first profile it finds (primarily for performance reasons - the less it has to look through the better (as its slow enumerating windows and processes, especially every time the mouse cursor moves!).

As you already have the "photoshop.exe" at the bottom of the list, the levels and screen profiles should take priority - if the cursor is over them AND if they are defined correctly.

My point about the screen profile is that is is defined "incorrectly" because you have said only match when there is no parent, yet specified a parent name to match - so in theory it should never match (and maybe that was the case in beta 14 and below. But I will look through the changes I made in order to understand better what is going on and decide how to proceed once I understand the issue in more detail.

@Kukurykus
Well, if main process profile is higher and the subclass profile has set that button to "No Change" then it should use action from main profile even when subclass is on hover. Can you reproduce it with another application? And does it work normally if subclass profile is turned off?

Edit: I've checked that the main process profile should be lower than the subclass profile. I thought it was other way around. Maybe Phil changed that.

@Phil
I forgot earlier to report one thing. When I copy a profile then the held actions are not copied. The button held action is chosen for the button, but it's undefined. Its setting aren't copied.

Edit: I've found another problem in application 7+ Taskbar Tweaker. When I go to Advanced Options and add a shortcut I have an edit box to put tekst. That field fits my profile for edit boxes and being marked in XMBC on hover. But when I click with any button then the profile is being unmarked and actions set to buttons in that profile (copy/paste) don't work. Funny thing is that when I open in XMBC a "Find Window" window then the actions suddenly work. So normally it doesn't work, but opening that window force it to work.

Edit2: I've set for default profile the 2nd layer activated with Shift to scroll left and right with general scroll. It seemed to work properly before, but now it doesn't for windows with defined profiles. So maybe Kukurykus point is that profiles block actions from other profiles (like default) even if they aren't set?

Beta 15 is not bad for some users expectations, but personally for me it would make too many problems. I hope another beta let choose at least by settings which behaviour we prefer for whole application. Surely that would be nicer to have it for each process (without dividing into subwindows), so we could have both behaviours for different applications if needed. Anyway that may need too much work from you, so just checkbox to turn on/off Beta 14/15 in preferences would be incredibly great solution!

Maxoku, yes - leaving certain subclass profile box empty on applications list does the job in Beta 15. The problem is that like in Beta 14 I can't do that as I work often with main process & its subclass at same time.

My point is that now when sublclass window is active then main process is immediatelly disabled (even while hovering outside of sublcass window area) I honestly would not like to duplicate main process commands to subclass buttons since sometimes I had to copy entire main process profile only becuase subclass got few commands. And the other problem with this solution would be that I couldn't copy all commands from main process to its subclass as I have already the same mice buttons assigned to other commands for that profile.

When you say "the the main process is disabled" - what do you mean - do you mean that XMBC does not select the main process's profile?
I'm sorry but its really difficult to translate!

If a sub window is open (levels) then you move the mouse outside, over the parent window then the parent process *should* activate. Simple as that. If its not, there is a bug going on (as I suspect). Debug log might be useful at this point (with some idea of the time when you hover between windows so I can line up the timestamps roughly) - but then that should be th first thing provided really

As I said before, hopefully I'll get a chance to look at it over the weekend. Before then - no way!

Probably I used wrong terminology, but I refered to something I said earlier, so better word could be not decetable, or detectable but not active.

In Beta 14 and earlier versions both main process and sublcass worked while hovering subclass window (with priority for subclass if both main process and subclass had assigned simkayes to same button), while hovering outside of subclass window area, a subclass process got deactivated to let main process be active.

In Beta 15 when subclass window is active then it works within sublcass window, while main process doesn't work neither within this subclass window nor outside.

Edit: I just wanted to make DEBUG log for you and found that in Beta 15 when I press button outside of subclass window it actually triggers main process command. So here I was wrong, probably because I misleaded myself by testing 2 subclass processes ('levels' that is only little window, and 'Screens' that is expanded for full screen).

Anyway the problem about not working main process within subclass window (when to the same button only main process has assigned some command) presists. The most annoying it's for full screen mode.

For example if in Beta 14 I had set in main process for middle button the ESC key then it would close 'Levels' or 'Full Screen Mode' while I'm within this Window / space area (on the condition the same key was free for subclass process). In Beta 15 I had additionally assign to each subclass process ESC key for middle button to get the same effect.

@Kukurykus
You're right. It's too much work to play with every profile to set the things from other profiles that should work normally with them. There should be an option to choose the behavior.
And when there's a conflict between two profiles assigning the same button then it should always choose the more specified profile (like with subclass instead of main process).

Yes - you completely understood my point in 2 most critical cases. Checkbox in preferences which of two behaviours an user would like to use, and that what stopped working in Beta 15, so possibility to use still assigned main profile button in subclass window (within its area) when the same button for the subclass window is not assigned.

Beta 15 is not bad for some users expectations, but personally for me it would make too many problems. I hope another beta let choose at least by settings which behaviour we prefer for whole application. Surely that would be nicer to have it for each process (without dividing into subwindows), so we could have both behaviours for different applications if needed. Anyway that may need too much work from you, so just checkbox to turn on/off Beta 14/15 in preferences would be incredibly great solution!

Your still talking like this was an intended change It was not. I still consider it a bug and I will be trying to put it back the way it was, not introduce more options (unless the way it was is simple not able to do what I wanted to do but right now I don't think that is the case)!
I just need to figure out exactly what "little" change has caused this .

I forgot earlier to report one thing. When I copy a profile then the held actions are not copied. The button held action is chosen for the button, but it's undefined. Its setting aren't copied.

Edit: I've found another problem in application 7+ Taskbar Tweaker. When I go to Advanced Options and add a shortcut I have an edit box to put tekst. That field fits my profile for edit boxes and being marked in XMBC on hover. But when I click with any button then the profile is being unmarked and actions set to buttons in that profile (copy/paste) don't work. Funny thing is that when I open in XMBC a "Find Window" window then the actions suddenly work. So normally it doesn't work, but opening that window force it to work.

Edit2: I've set for default profile the 2nd layer activated with Shift to scroll left and right with general scroll. It seemed to work properly before, but now it doesn't for windows with defined profiles. So maybe Kukurykus point is that profiles block actions from other profiles (like default) even if they aren't set?

Thanks for that info, I have 7+ taskbar tweaker so hopefully I can reproduce this one here - it will make testing easier if I can actually reproduce the problem easily (as I don't have photoshop to test Kukurykus's issue directly).