Attached stickies, API, and 'attach when focussed'

First of all, thank you very much for your absolutely excellent program!

I hope you can clarify a few attachment-related issues for me. I am using Stickies 10.0d under Win7/x64/SP1.

Goal: I would like an attached sticky (that is not set to be always on top) to become visible whenever the window it's attached to becomes focused.

I have had some partial success by manually setting the note's property 45 "attach when focussed" to 1 in the database. Things work almost the way I thought they should. For example, with a note attached to the Calculator, whenever the Calculator gets focused, the note appears. Unfortunately, that's just about the only thing that happens as I expected. Here's what I consider problematic with the way things currently work (marked with letters):

• When Calculator is focused, the note gets displayed (as mentioned earlier), and: A) the note is shown as if it has focus (with a blinking caret) even though it is the Calculator that really has input focus, B) the note is shown behind the Calculator (this is sort of understandable, but it obviously won't do any good for maximized programs or situations where a program simply covers the note).
  
• When Calculator loses focus, C) the note gets hidden - even if the Calculator is still visible (again, understandable, but not really desirable).
  
• As a side-effect of the above, D) it's impossible to focus the note: focusing it un-focuses the Calculator, so the note gets hidden.
  

Here's my idea of how it should possibly work.
When the window of interest (e.g., Calculator) is focused, the note is brought to the top of the Z-order (e.g., by means of setting its window to be always-on-top and immediately clearing that flag). The above operation should not focus the note - just make it appear above the now focused Calculator (or what have you). In my limited experience, that's how it works under Win7.
And... that's it! When Calculator loses focus, don't do anything. Let the note float around (along with the Calculator itself). This will also allow the note to be focused and edited without it vanishing.

What do you think? If the above sounds reasonable and you end up implementing it at some point, it'd be great to also get a new checkbox in the window-picking dialog for this "attach when focussed" feature.


And now a few API questions, if I may. Using (mostly) your api.exe, I am getting:
get list attached -> 001 3,
get attached 3 encoded ->
returns when Calculator is not running: 999 Not understood
and when Calculator is running (and the sticky is even visible): 998 closed sticky not found
Is this the way it's supposed to work or am I doing something wrong? Basically, the get attached command doesn't seem to work for me at all.

There's no API command to set attached configuring the note's parameters, is there? In particular, to set the ATTACHFOCUS field? I probably won't need this if the "attach when focussed" feature becomes available and gets friendlier, but I was considering manipulating notes via AutoHotkey.

BTW, you may wish to clarify in the Help that commands are to be prefixed with 'api': api do ping, and so on. It's very clear from the samples' source code, but I don't think I saw it explicitly indicated in the documentation.

Thank you once again!

Congrats for reading the database guide closely enough to spot a part-implemented function!  It's nice to know that at least one other person in the world has opened that sheet I put together.  To be honest I've referred to it myself a number of times so it proves the value of writing documentation.

You're finding out why the feature never made it into production though.  I've always struggled with getting note windows to come to the front in the right way, across a number of versions of Windows, and on many machines.  It ought to be simple to tell a window to come to the front without stealing focus.  Except of course for the times that you do want it to "steal" focus - and MS added security to prevent apps from stealing focus a while back.  The upshot is that I've never had exact control over that part of the app, and although it mostly works correctly, sometimes that doesn't happen.

One thing to suggest - if you change the setting "Clicking one note brings all notes to the front", that might help?  Technically, it alters the parent window of all notes from being a hidden Stickies window to being unowned.

Checking back through the code, it seems I made a mistake with "get attached xxx encoded".  The code is there, but commented out.  I think as I was re-writing all the storage code to use the .db file I commented something not working (it used to get content from am RTF file) so that the exe would at least compile.  That was a big job, ripping the file handing underside of the app out and replacing it with database routines.  Anyway, looks like I left the code commented out, and never went back and fixed it up.  An exe with the code which should have been there already is at this link:

https://www.zhornsoftware.co.uk/stickies/stickies100e.zip

I'm sorry for missing that out - I hope you didn't spend too long banging your head against it trying to get it to work, when it was never going to...   

Would you find a couple more API commands useful:

set attached 1234attachtitle xxxyyyzzzz
set attached 1234 attachclass aaabbbbccc

I could add those to the build above?

That's a good suggestion to clarify the API usage thanks - when at the Windows API level, prefix strings with "api".  I've made a note on the API page.

Tom

I have just tested the 10.0e 2020-04-22 build, and I am happy to confirm that the get attached N encoded command now works properly, thank you!

Regarding your suggested "set attached" commands, thank you for the offer, but...
1) Personally, I do not foresee needing those, so I only pointed out their absence in terms of general API completeness.
2) Even the current releases of Stickies have more attachment-related features than mere title & class, so a full API implementation would probably require some way of setting everything that exists.

My personal inclination would be towards something akin to a function call with optional parameters. For example:
set attached NNN <ATTACHTITLE>Calculator<ATTACHCLASS>CalcFrame<ATTACHFOCUS>0<ATTACHVISIBLE>0<X>-1<Y>-1
Absence of a parameter (or a 'special' value like -1) could be interpreted as blank or unused as appropriate. X and Y >= 0 could indicate "Attaching with position".
Of course, this would stand in stark contrast with the rest of the API, so maybe it'd be too inelegant a solution.


Now, regarding that pesky "ATTACHFOCUS" subject...

The "Clicking one note brings all notes to the front" setting doesn't really help, I think (I tend to keep it disabled).

Yes, I know that Windows likes to interfere with bring-to-front or focusing. MS started their holy war against apps stealing focus probably right after NT 4.0, which may have been the last OS version that handled windowing competently and reliably. Having said that...

Do you know any 'modern' version of Windows that do not respond as expected/desired to my suggested approach of "always-on-top set + unset"? I have only tested it (briefly) under Win7/x64 (with no registry changes that would affect window/focus-management that I can think of), and under Win7 this method seems to work great. But yes, I am perfectly willing to believe that MS broke even that in some other version(s). If you know which one(s), I'd appreciate it if you could let me know. Maybe I'll find a workaround for those some day. Or not.

Even if that "bring to top without focusing" approach only works for some Windows versions, seeing as that'd be a (non-default) option, perhaps it wouldn't be too damaging to enable its use via a checkbox? It could come with a caveat saying that "this feature may not work, in which case blame Microsoft and Invector" .

I was changing the bed yesterday thinking about what you suggested - that all new notes are brought to the front of the z-order by making them on-top, and than taking that setting off (depending on whether the note ought to be on-top anyway).

I've made the change in my development code here, and I'll run with it for a while to see if it improves matters.  There's an argument that waking notes don't need to come to the front, but just appear on screen, but I think there's a better argument that they should appear in front of everything else, even with on-top not set.

Tom

Thanks, Tom, sounds great. Let me (well, all of us) know if/when something is ready for testing.