@trixie This is really awesome. The popup on the multiassign is a hidden chooser? So, you check the node at the listbrowser for multiassigns and you dynamically create a hidden chooser?
Do you use UserData to keep that information on the node, or something else?
Do you have any idea of an approximate release date?
As I explained in the blog post, things unfortunately got delayed due to the lockdown parenting hell, but I'll definitely give you something to play with this summer.
The popup on the multiassign is a hidden chooser? So, you check the node at the listbrowser for multiassigns and you dynamically create a hidden chooser? Do you use UserData to keep that information on the node, or something else?
I scan the DOS volumelist for the current list of volumes and assigns, and if a specific assign is marked as a multi-assign, I scan it for the associated paths. These end up on a Chooser list, which I store within the respective ListBrowser node. But I don't use LBNA_UserData for this. Instead, each ListBrowser node in the requester's list of assigns is allocated as a custom node via AllocListBrowserNode() and LBNA_NodeSize (which has the size of my custom node structure). The Chooser list is then stored as a pointer in the custom node structure.
The advantage of this is that upon selection, I can simply GetAttr() the LISTBROWSER_SelectedNode attribute and read the Chooser list pointer from the node structure. In other words, I spare a subsequent GetListBrowserNodeAttrs() call to retrieve LBNA_UserData.
The multi-assign path selector is indeed a hidden chooser. I create one such chooser for the file requester. When a multi-assign gets double-clicked, I retrieve the Chooser list pointer from the ListBrowser node, set CHOOSER_Labels to point to the respective list, and then open the hidden chooser via ActivateGadget().
Of course I have a notification on the DOS volumelist, so the list of volumes and assigns gets rebuilt with every change reported by DOS. I also rebuild the list whenever the file requester reopens.
@trixie Pretty smart way to do it. Thank you for the explanation. Did you see any slow downs on requester open? When you do the first scan? When you start the application or when the user first open the requester? Have you tried it on Sam440 you have to see how fast it is?
Instead of a chooser, did you try with Hierachical nodes/entries (those with [+]) or does it mess everything up?
I was considering hierarchical nodes, but in the end I settled for the chooser. The reason is that the multi-assign path strings can get quite long and won't fit in the listbrowser area. So you'll have to use a horizontal scroller to see the paths in full. This is more awkward than simply selecting from the chooser pop-up. Another reason is that the standard system ASL requester uses a similar solution: when you double-click on a multi-assign, a pop-up selector opens.
Did you see any slow downs on requester open? When you do the first scan? When you start the application or when the user first open the requester?
At application start-up I only build the requester object (including GUI). I scan the DOS volumelist whenever the user opens the requester (and, as I mentioned above, when there is a change notification from DOS).
Quote:
Have you tried it on Sam440 you have to see how fast it is?
My Sam440ep-Flex is currently in storage, waiting for me to find time to install Update 2 on it. But I've tested the program under emulation (OS4.1 for Classic in WinUAE), and the requester opens almost immediately. So I'd say the volumes/assigns scan is fast. And I can tell you that my emulated system is much slower than the Sam440.
But I've tested the program under emulation (OS4.1 for Classic in WinUAE), and the requester opens almost immediately. So I'd say the volumes/assigns scan is fast. And I can tell you that my emulated system is much slower than the Sam440.
@trixie Thank you so much for this update. What you implemented there is exceptional. Reading this post got me asking more like "What?" and "How this can be done?" and at the end realizing how many things I need to learn to catch up with this implementations. I need to learn a lot.
At the point where you talked about the vacation time you took, but you are doing more work, it reminded me last Easter where I got a week of annual leave from my daily job and worked only on MediaVault and learning new stuff. That made me feel so happy and good, by working on these machines, that I want to repeat it again in the first chance.
Looking forward for your next update and of' course, the Rave release. Keep it up man.
Reading this post got me asking more like "What?" and "How this can be done?" and at the end realizing how many things I need to learn to catch up with this implementations.
Frankly, I wrote the update specifically with you in mind because you asked for more details on how things are done in code. I'm glad you've found some food for thought in it - feel free to ask if you want to know more! And don't worry: you'll learn along the way as you work on your own projects. Was the same for me.
Quote:
it reminded me last Easter where I got a week of annual leave from my daily job and worked only on MediaVault and learning new stuff. That made me feel so happy and good, by working on these machines
Yes, these things can feel very rewarding! By the way, I've been using your MediaVault all the time this summer, tuning in and listening to various online radios as I worked on Rave.
For those of you who do Facebook: some time ago I set up a Facebook page related to my software projects. And now - because writing blog posts can get quite time-consuming - I've decided to publish smaller progress updates and WIP screenshots on that Facebook page. You're very welcome to follow me.
Should we wait for a new demo from you guys? Or am I pushing too much? :D
Actually, we are working on a new demo, which we'd like to release at the Revision demoparty in spring. I only hope we'll be able to finish it in time.