Are there ways to assign notes to specific columns and rows location on monthly calendar adornment when I set conditions as its query order?
No, or not with any ease. My recollection is grids were an affordance for manual placement of notes. Also, if you are using a continuous query to gather notes, then the agent controls note placement and I don’t think you can reach inside that process. You also need to consider the edge cases. What if all the notes need to do in box #17, how will you see them all? Don’t assume these issues won’t occur.
With all that in mind, there might be a way. first you need to know the adornment’s $Xpos, $Ypos, $Width, $Height, $GridRows & $GridColumns; plus the $Width & $Height of a note. With that you could then work out the size and map location of each grid box. Based on that you might be able to use the smart adornment’s $Rule to place items. Of course, if you more or resize the adornment you need to recalculate. But without even trying this it sounds like something so complex as to likely be easily broken.
Does this layout have to be used or is this just based on a diary-like condensed month layout? I ask as depending on the assumptions/constraints of the underlying task there might be a solution. IOW, is seeing on what day a note falls due more important than the exact look of the layout or vice versa. Or, consider just pass info out into a calendaring app.
Or make a grid of individual adornments. Once you set it up it seems like you could copy and paste as needed for future months.
1 Like
I did think of that. Indeed you could make up a a composite. But it feels like a kludge. I’m guessing the OP will expect to see all items in a grid box and assume that the grid will likely scale to accommodate this. So this issue with lots of adornments is less detecting the right adornment/cell but the overall usability once you start adding all your data.
IOW, I get the concept, but it’s not one I’d advise with current functionality. It’s just go for {x,y} position and use some line-adornments and label notes to make a ‘grid’.
Thank you for all your advises. (pardon for lately replying, due to some private reasons). I probably might try to use agents instead of adornments in collecting periodical tasks.
I’ve created an example file of Action Code that adjusts the position to fit the adornment grid and a calendar of adornment. I’ll share it.
AdornmentGridDemo.tbx (746.4 KB)
3 Likes
I’ve tried this in several ways. It is. It does not scale. the manual dragging on to a grid is fine. Ideally, placing the item on a grid would trigger relevant action. Again, I’ve not found a way for this to scale.
In what way would this not scale? And does it have to?
If you’re working with a month planner, you’ll never have a month with more than 31 days. So you don’t need to scale for number of day.
Of course, the visualization that @sazanamix proposes only makes sense if each day holds at most one item. That’s all you need if you’re scheduling performances and rehearsals for the Miskatonic Symphony. Symphony orchestras seldom play double-headers. If you might need 20 notes in some bins, this isn’t a good way to proceed.
People have lots of planning tasks where each day (or class meeting, or whatnot) has zero or one events. If the event knows its date, this is a clever way to automatically arrange a pile of events.
1 Like
All good points; perhaps I’ve not stumbled across the right use case for myself yet. I did try doing this for event that had several sessions, each with 1~5 speakers, and managing the overlaps became complicated. But that was a while ago. Maybe, with my recent TBX skills-evolution, the answer may be more apparent to me.
Mr. Michael Becker and Mr. Mark Bernstein
Thank you for your comment.
@satikusala you are right, a calendar grid is not very practical.
Adjustment of grid position may be useful for some applications.
I was thinking of sharing just a demo of adjusting the position to the center of the grid.
There was a thread here and it looked like it could be achieved if applied, so I just thought it might be useful for someone else to try it out.
(I tend to keep my explanations short because of the time it takes to write English text. Sorry about poor English too. 
)
P.S.
I am always learning from you both on forums and training videos.
Thank you very much.
2 Likes
Thanks for your contribution. Little demos are always welcome 
and we appreciate the extra effort involved in having to translate explanations to English.
I think—unintentionally—two aspects of the experiment got mixed here. One is the ‘can I …?’ as explored in your demo, and the other is ‘does the idea work in a more general setting?’ as in later comments. The latter doesn’t cancel the former. So there is no right/wrong here. The usefulness or re-use of an approach depends on context. 
Also, as many experienced users will confirm, trying is the first step to finding out if an approach works.
The challenge with grids is Tinderbox controls where in the grid a note goes. If there is only ever going to be one note per grid box, e.g. @eastgate’s example above, then the approach here offers a simple way to organise notes based on single discrete values. If the values are not discrete, i.e. you may get more than one item per box, the convenience of Tinderbox auto-positioning the notes goes away as you don’t have fine control of position. So, for example, two notes might overlap stopping you fully reading note titles.
2 Likes
Thanks for the reply.
As you said, the two experiments have been mixed up.
Your precise explanation made it clear to me that I should have simplified them separately.
If I find a good demo, I will post it.
P.S.
I have always found aTbRef to be helpful.
I would like to take this opportunity to thank you.
2 Likes