CEA - Custom Event Actions

[admin]

Honestly, it's not that big a deal to me. I thought seeing "load D:\Tools\XYplorer\Scripts\CEA_MiddleClickMenu.xys" or even a part of it was a bit much and not that aesthetically pleasing. ...

I agree, it's not aesthetically pleasing. One day I'll do something about that.

[autocart]

Honestly, it's not that big a deal to me. I thought seeing "load D:\Tools\XYplorer\Scripts\CEA_MiddleClickMenu.xys" or even a part of it was a bit much and not that aesthetically pleasing. ...

I agree, it's not aesthetically pleasing. One day I'll do something about that.

What I would find an improvement, if only the first line would be shown. Right now, as I last tested, if the first line is super short, then the first part of the second line is shown too. Just the first line would be better, semantically and aesthetically.

[admin]

Oh yes.

[autocart]

... but it doesn't look that great either. /*Double-Click script*/ ... and of course that ends up in the ini file as well. ...

That comment and the talk about the script column in the config dialog not looking pretty enough... I thought a bit if I should comment or not because I don't want to offend anyone but I think it is not good for XY to give such thoughts about "looks" too much room when developing new features.

Therefore I must say that the first concern regarding the config dialog and the ini file and similar contexts (actually about the whole program) should be about whether the solutions are practical or not. Looks can come after that - with a big distance so to not run into the danger of the one bumping into the other. To not like some practical idea just because its not "pretty" enough, is crazy.

Of course, I might be one of very few people finding the script column practical like that, and I am open for good arguments on that level. I am sure there can be more practical solutions. But as long as nothing of same or better practicality is found, then the "looks" should not be the determining factor.

No harm meant. I hope no one is offended.

[LittleBiG]

Ha!, I finally found the code that's called before showing the hover box, and it's only called in a multi-monitor situation! I will now use the same code before showing config, that should solve it. Remains a mystery why it's necessary, but Windows is full of mysteries...

And yes, indeed it solved the problem on the first monitor, thanks for it. But if I move XY to the secondary one and open it from there, I will get the vertical scrollbars, no matter what. Showing hover box doesn't help on secondary monitor.
screen command:

Code: Select all

Virtual Screen: (0, 0) - (3200, 1170)

Screen.Width (screenW) = 1920 (1920)
Screen.Height (screenH) = 1080 (1080)
Current Monitor: 2 (Secondary)
Current Work Area: (1920, 146) - (3200, 1130)

Number of Monitors: 2
Monitor 1 Area:      (0, 0) - (1920, 1080) = 1920x1080
Monitor 1 Area Work: (0, 0) - (1920, 1030)
Monitor 2 Area:      (1920, 146) - (3200, 1170) = 1280x1024
Monitor 2 Area Work: (1920, 146) - (3200, 1130)

Startup Work Area: (0, 0) - (1920, 1030)
GetCursorPos = 3069, 223
XY Main Window: (1911, 137) - (3209, 1139) = 1298x1002

Screen DPI: 120 (125%)   twX: 12 (12)   Stretch: 1   sLF: 1,25   Toolbar Zoom: 1 (1;1)
Screen Color Depth: 32
DPI awareness: Per monitor
Auto Scaling: Yes, Yes

[admin]

Can you show a screenshot of that whole screen with the config dialog?

[LittleBiG]

Can you show a screenshot of that whole screen with the config dialog?

[klownboy]

Of course, I might be one of very few people finding the script column practical like that, and I am open for good arguments on that level. I am sure there can be more practical solutions. But as long as nothing of same or better practicality is found, then the "looks" should not be the determining factor.

Hi autocart, as I mentioned, it's really not that big a deal to me. Whatever Don ends up with is more than fine. I know you brought up making the script visible in the interface and you also want to see that whatever is done is practical. To me seeing the script file is a good idea, but it does have to be presented properly. I think Don and other good developers know that the program's interface has to be more than just practical and functional, it does at the same time have to look good.

Sure I made some comments, but as old as I am, I'm really not overly concerned about how, as you say, "pretty" it is. On the other hand, Don does have to be to be concerned about how John and Mary NewUser see the Configuration interface. If they see something that's perplexing or confusing, it may cause them to shy away and maybe Don's lost a potential customer. I sincerely didn't mean to be pushing hard in any direction and certainly don't want to be cause of any hard feelings. I can go with the flow and I'm certainly not offended. Thanks and take care.

[autocart]

I assume that we both, klownboy, generally have the same thoughts of what is important but it seems we both emphazise them differently by the way we word them. Thus, I do not feel fully understood by you and vice versa probably you too don't feel that way with me, yet we probably mean the same things. Still, I am thankful that I was allowed to word my concerns. Now I have my peace and you are right that it is not extremely important. In the end, I also think that Don will find a way that will be ok. And thank you for explaining yourself again. Take care as well.

[autocart]

Oh, and Don, congratulations on turning 50,000. I just now noticed it that it must have happened just recently, now with 50,081.

[highend]

If captions are named "Clicking on White" and "Clicking on Tabs" (which both make sense),
don't you think that every item underneath can have their "on white", "on tab" in their event name removed?
Quite "doppelt gemoppelt"...

[klownboy]

Looking good Don. I think highend's right though. It is probably redundant and unnecessary to see "on white" or "on tab" in the event again.

[admin]

If captions are named "Clicking on White" and "Clicking on Tabs" (which both make sense),
don't you think that every item underneath can have their "on white", "on tab" in their event name removed?
Quite "doppelt gemoppelt"...

I know, but this way it's easier to talk about the setting and send users to the right place. Also "Jump To Setting" it makes more sense like this.

[admin]

English question: Is "None" a good choice in the Action column? Or should it be "Nothing"?

[highend]

Imho "None" is concise and considerable shorter...

Will you implement the equivalent to <get trigger menushift>, e.g. <get trigger eventshift> so that we can use all keyboard modifiers (incl. alt) for belonging scripts?