You can check the ones that are only volumes/devices (no drawers in path) and open Filer. PathPart() can be handy IMO. ... EXAMPLE PathPart("xxx:yyy/zzz/file") would return a pointer to the last '/' PathPart("xxx:dir") would return a pointer to the 'd'). PathPart("xxx:dir/") would return a pointer to the '/'. PathPart("xxx:") would return a pointer to the nul terminator. PathPart("nopath") would return a pointer to the letter 'n'. ....
and I get something like this: #getSelIcons getSelIcons(): 0x56110B30 [0]'Devel:sdkbrowser' [0]'Devel:PortableE' [0]'Devel:tIDE_0.1' [1]'RAM Disk:' [1]'SDH6:' [1]'PRUEBAS:' #
Now, when i click just on one icon, it return me path for one icon, one time all ok. If i select 2 icons, and click on any of them, it return me paths for 2 icons twice (!). I.e. if i choose Ram: and SFS2: partitions, i do have in output:
'RAM Disk:' 'sfs2:' 'RAM Disk:' 'sfs2:'
Same with your test case you send me, also ok when one icon, and twice when 2 icons. If i select 3 icons at once, and click on one of them , i have then repeat 3 times output. Like, depends on how many icons selected, it will the same many times print out all of them :)
Doesn't look trivial thing, 'cos WB “does” an OpenWin() call for every icon (on multiple icons start), so seems not easy to find out a solution.
Yep... We need somehow to detect that it was "selected and one time dbl-clicked", so while continue to do all the opening as before for every icon, do have some sort of flag or check which will mean "check list of selected icons one time".
Or, maybe we need to "compare" the returned list : i.e. it will be done as many times as many icons selected, so, we save first output, and then for each other compare : if it the same, then do nothing. So only first one will be taken. Of course, it will waste compare-loops, but at least better that nothing for a start..
something like (pseudo-code of course, not exactly secList to compare, maybe nodes, etc):
.
struct List *selList = NULL;
struct List *selList_prev = NULL;
if ((IWorkbench->WorkbenchControl(NULL, WBCTRLA_GetSelectedIconList, &selList, TAG_DONE)) == TRUE)
{
Maybe unselecting icons will work. I mean: 1)User select some volumes with shift and clicks on one of them. 2)Using WBCTRLA_GetSelectedIconList open all Filer "instances" 3)Deselect all icons using ChangeWorkbenchSelection(NULL, &hook, TAG_END);
...
struct Hook hook;
BOOL UnSelectIcon(struct Hook *hook, APTR reserved, struct IconSelectMsg *ism)
{
// If the name matches, select it. Otherwise, leave its
// select state alone.
Printf("UnSelectIcon(): '%s'\n",ism->ism_Name);
return (ISMACTION_Unselect);
@Javier Nah, hardcore deselecting is kind of broken the visuals, as they keep selected even after you run them.
Need to find a way how to not handle the whole list many times in one OpenWindowTagList(), but only one time for each entry in node.
@All Anyone have an ideas how to made it in clean and better way ?:) I also think that maybe need to check, if we hit one time "dbl-click", then only do getsellist one time.. But that kind of not clean too..
@kas1e Wiki.amigaos.net do not have entry for whichworkbenchobject() maybe it’s just in the SDK, definitely not present in AmigaOS 3 by looking At the doc, might have to look at the latest 3.2 NDK though.
Anyone have an ideas how to made it in clean and better way ?
Seems like a good idea to get rid of the WhichWorkbenchObject() stuff and just use the list of selected icons to find out which drawer to point Filer at. That should cure the problem where using 'Open' from the Workbench menu opens a Workbench window rather than a Filer.
As far as handling multiple icons, here's one possible way of doing it, presented in pseudocode, so I don't have to worry about getting the syntax exactly right.
First, create a global variable called 'which_icon', which defaults to zero (computer numbering, where 0 is the first icon, 1 the second, etc.)
Now replace the WhichWorkbenchObject() code with something along the lines of:
Use WorkbenchControl() and WBCTRLA_GetSelectedIconList to get the list of selected icons. Get the first icon from the list (GetHead()).
Call GetSucc() 'which_icon' times, to get the which_icon'th entry in the list. Check to see if there's another list entry beyond this one (GetSucc() doesn't return NULL). If so, increment which_icon for next time. If not, reset which_icon to zero.
Get the drawer's name from the list node and either pass it on to Original_OpenWindowTagList() or open a Filer and pass the drawer name to it. You don't have access to the icon type, so you'll need to look for a ':' at the end of the name to tell if it's a disk icon or not.
Free the selected icon list with WorkbenchControl() and WBCTRLA_FreeSelectedIconList.
The idea is that if more than one icon is selected, then each time OpenWindowTagList() is called one of the selected icons will have its window opened. The which_icon variable keeps track of the next entry in the list, the one that will have its window opened the next time OpenWindowTagList() is called. Once the last entry has had its window opened the variable resets to the first entry again for next time.
To keep the pseudocode easier to follow I left out error handling, such as dealing with cases where there are no selected icons (the list is empty), or if the list unexpectedly ends (the which_icon'th entry doesn't exist).
if (Caller == NULL ) {
return Original_OpenWindowTagList(Self,nw, tagList);
}
// checking if this is WB window which we need to patch
if (nw && !stricmp(Caller->tc_Node.ln_Name, "Workbench") && (nw->Flags & WFLG_WBENCHWINDOW) && !(nw->Flags & WFLG_BACKDROP))
{
struct List *selList = NULL;
But then, when i run "wbrun work:" or "wbrun system:utilities", i simple crashes. Because before, i just did this:
// we hijack only WBDISK types, so commands like "wbrun" and Filer's "Workbench Folder" works as before
if (type != WBDISK) {
return Original_OpenWindowTagList(Self,nw, tagList);
};
So i had to put this one also back. And then wbrun works too, but then again, while "multiply selected icons" handled properly now, i back to the same issue , when i select an icon on workbench, and hit "open" , and mouse cursor are a bit "out" of the icon, and it open old workbench window.
Can we somehow get the type of selected icon, without relying on the mouse cursor position (so, if icon selected, then any kind of open from any move , will check exactly selected icons on WBDISK) ?
Edited by kas1e on 2023/12/4 13:23:38 Edited by kas1e on 2023/12/4 14:00:44 Edited by kas1e on 2023/12/4 14:37:44
But then, when i run "wbrun work:" or "wbrun system:utilities", i simple crashes
That's probably because when you use wbrun there are no selected icons, so the selected icon list is empty and GetHead() returns NULL. When you try to feed that to GetSucc() or to reference the ln->Name it of course doesn't like that. You need to add a bit of the error handling I mentioned- in this case, if GetHead() returns NULL just call Original_OpenWindowTagList().
That's probably because when you use wbrun there are no selected icons, so the selected icon list is empty and GetHead() returns NULL. When you try to feed that to GetSucc() or to reference the ln->Name it of course doesn't like that. You need to add a bit of the error handling I mentioned- in this case, if GetHead() returns NULL just call Original_OpenWindowTagList().
Right, that one works. But then, we in some situation now:
If we use new WorkbenchControl()/WBCTRLA_GetSelectedIconList way, then
-- dbl-click works -- selection of many icons works -- open from WB works does not matter where mouse cursor are
BUT! if you do:
1). select an icon 2). dbl-click on it (it run filer, all ok) 3). then, in Filer, do "Workbench Folder", and it will open Filer again : that because our icon is still selected on WB.
Or the same if you do:
1). run a shell 2). select an icon 3). dbl-click on it (so it gets selected even after Filer runs) 4). click on shell , and type "wbrun anything" -> it will open in Filer, because icon is still selected.
So, or we use WhichWorkbenchObject() + WBDISK type checking, and all works, but then "Open" from workbench will not work, once you move mouse away from the icon, because WhichWorkbenchObject() uses MouseX/MouseY position.
Or, we do use new way with WorkbenchControl()/WBCTRLA_GetSelectedIconList, but then, while icon is still selected (and after operation with it it still stays selected), wbrun and Filer's "workbench folder" didn't works as expected to open old WB window, but instead Filers.
So far it looks like that the way to deal with, is to use our new way + as Javier says made hardcore "UnSelection" after run, but then, it change the way how workbench works by default..
Dunno how else we can handle all cases ? Because or we check via MouseX/Y, then Open from WB not works when mouse is not exactly over the icon, but all other works, or we check Selection, but then it will work when we not need it as well and we need hardcore unselection after we run a Filer.
@all Together with the latest issue i pointed out about in previous post, i think we also need to deal with "don't run second time if already opened this device".
I think we can go WBCTRLA_GetOpenDrawerList way firstly i.e. in the patched OpenWindowTag, once we have our scanning code checking entries, run the WBCTRLA_GetOpenDrawerList before, to have a list of already opened drawers. And then compare with the list we had form scanning of selected icons, and the ones already opened can be skipped, but then, Filer's window is not Workbench's window sadly .. If only we can add some "flag" somehow to the running Filer saying that this is WB-window, then it may work ..
Edited by kas1e on 2023/12/5 12:04:43 Edited by kas1e on 2023/12/5 12:05:23 Edited by kas1e on 2023/12/5 13:13:47
then, in Filer, do "Workbench Folder", and it will open Filer again : that because our icon is still selected on WB. ... click on shell , and type "wbrun anything" -> it will open in Filer, because icon is still selected.
Yea, I anticipated that would be the next problem encountered, and was going to point it out if you hadn't discovered it. I'm not sure what we can do about it, though. I think we've about reached the limit of what a simple patch can do.
The problem is that there are two different scenarios for Workbench opening windows, one that involves opening icons that are selected, and one that doesn't. Workbench doesn't make that information available, so the patch has no way of knowing which one is in use, and has to make an assumption. Which means it's always going to be wrong part of the time.
We can try to add increasingly complex patches and hacks to try to track or deduce what Workbench is up to, but we're getting to the point of diminishing returns. And all this is running inside a call to OpenWindowTagList(), so a lot of complex manipulation is probably not a good idea.
Quote:
Filer's window is not Workbench's window sadly
There's even less information available about what Filer is doing than there is about Workbench. And unlike Workbench windows, Filer windows can be changed to point to a different location than what was originally opened, which could make tracking them even harder.