I have one time original WB window, all other clicks are working now. Seems resetting should be done early somehow as well. But i fear it also because of "filer run it once", and which icon counter mess a bit.
I'd have to study the code a bit to be certain, but which_icon should probably be set to zero any time that Original_OpenWindowTagList() is called.
Quote:
the only situation when it will not work, is when user will move the window exactly on the 0 and somehow keep selected some icons.
As you noted, checking the left edge of the active window will fail if the Filer window or the shell window where you're running WBRun is at the left edge of the screen. Unlikely, but possible.
Would it be sufficient to just check the active window for WFLG_WBENCHWINDOW and WFLG_BACKDROP? The Workbench backdrop window should be the only one that has both those flags set. And that's the only window where disk icons will be found.
Though as I think about it, there is a actually a way to make both those methods fail: Open a non-disk icon, which will result in a normal Workbench drawer window. Now single-click a disk icon on the backdrop window to select it and make the backdrop window the active window. Click the border of the drawer window to make it the active window instead, without deselecting the icon. Now use the Workbench "Open" menu to open the selected icon. It will open as a regular Workbench window instead of as a Filer, since the active window is neither a backdrop window nor is at the left edge of the screen.
Quote:
At least it surely better to have it as very rare corner case (and note in readme about) in compare with adding more complexity and have other bugs with.
Agreed. It's probably not possible to make it work perfectly every time no matter what; we'll always be able to come up with some unlikely but possible way to make it misbehave. If it works properly for the way that most people will use it, and doesn't crash no matter what, that's probably as good as it's going to get.
Would it be sufficient to just check the active window for WFLG_WBENCHWINDOW and WFLG_BACKDROP? The Workbench backdrop window should be the only one that has both those flags set. And that's the only window where disk icons will be found.
As far as i test, and Filer and shell window both have same WFLG_WBENCHWINDOW and WFLG_BACKDROP flags. And btw this WFLG_BACKDROP is misleading by name : like, it's desktop's backdrop, but it's not:
Quote:
Backdrop Window Type Backdrop windows open behind all other non-backdrop windows, but in front of other backdrop windows that might already be open. Depth arrangement of a backdrop window affects the order of the window relative to other backdrop windows, but backdrop windows always stay behind all non-backdrop windows. No amount of depth arrangement will ever move a non-backdrop window behind a backdrop window.
The only system gadget that can be attached to a backdrop window is the closewindow gadget. Application gadgets are not restricted in backdrop windows.
Backdrop windows may often be used in place of drawing directly into the display memory of a custom screen. Such a technique is preferred, as backdrop windows are compatible with the Intuition windowing system. Using a backdrop window eliminates the danger of writing to the screen memory at a "bad" time or at the wrong position and overwriting data in a window.
To provide a full screen display area that is compatible with the windowing system, create a full sized, borderless, backdrop window with no system gadgets. Use the ShowTitle() call to hide or reveal the screen's title bar, as appropriate. See the SDK for a complete list of arguments for ShowTitle().
Backdrop windows are created by specifying the WFLG_BACKDROP flag or the WA_Backdrop tag in the OpenWindowTagList() call.
Quote:
Though as I think about it, there is a actually a way to make both those methods fail: Open a non-disk icon, which will result in a normal Workbench drawer window. Now single-click a disk icon on the backdrop window to select it and make the backdrop window the active window. Click the border of the drawer window to make it the active window instead, without deselecting the icon. Now use the Workbench "Open" menu to open the selected icon. It will open as a regular Workbench window instead of as a Filer, since the active window is neither a backdrop window nor is at the left edge of the screen.
For me when i hit on the border of the window with opened WB drawer , it start to be active, and the selection from Workbench one unselects.
But i think i find the way to reproduce what you mean, just a bit different:
-- open RAM: via "wbrun" (or from Filer) -- now, while it casual wb window, just select 2 icons on desktop : RAM one, and any other one -- dbl-click on them, and while first window will not opens (that clear, as RAM already opened) it will open in the same casual window a next disk, and not in Filer's mode.
Some more check need it seems so ?
@Joerg
Yeah, thanks! ActiveWindow->BorderTop is surely better. All active windows i test so far always have in my case BorderTop = 25, and only when Workbench Desktop window active it says 0.
But then, it also says 0 for BorderTop too, so maybe something like:
ULONG lock = IIntuition->LockIBase(0);
int BorderTop = ((struct IntuitionBase *)IntuitionBase)->ActiveWindow->BorderTop;
int LeftEdge = ((struct IntuitionBase *)IntuitionBase)->ActiveWindow->LeftEdge;
IIntuition->UnlockIBase(lock);
@kas1e This is getting quite simple now. Only a few more left:
- You still have unneeded parenthesis in if ((IWorkbench->WorkbenchControl(NULL, WBCTRLA_GetSelectedIconList, &selList, TAG_DONE)) == FALSE) { No () needed around function call (or may even write !IWorkbench->WorkbenchControl) instead of == FALSE but comparing to FALSE is OK if you think a ! is easy to miss and rather write it explicitly but less () is still enough anyway).
- Now there are more comments than code, some of the comment may not be necessary or helpful so you could prune them a bit. For example:
// (inverting condition check done for easy code-reading and to avoid of the distang else)
belongs to change log or commit message, not in code comment,
// Firstly define a flag for final error checking and code simplification
does not tell what code simplification you mean, maybe just explain what it is for: // Flag for error return: FALSE there was an error, TRUE no error or similar.
You could review other comments and simlify them. In general clean code does not need much comments because it's clear what it does. Comments that just state what the next line does usually aren't helpful unless there's something tricky in those lines. Explaining trivial things should not be needed so comments need to only note things that are not obvious from code.
I can't really comment on the other problem of finding out when called from workbench but is there a way to get the parent or container of the selected icon? If so you could check if that's the workbench background window rather than trying to identify it by its position or size. Ot if you already have the parent of the icon then is there a way to query the what is the workbench window to compare the two? I don't know anything about how that works so can't really help with that.
@All Well, the check on the ActiveWindow LeftEdge + BorderTop are ok, but then, if i hit "amiga+e" and type "wbrun ram:", while "ram" selected on workbench, then it again run Filer instead of plain wb window because when we do it like this we have no window from which we run it...
Dunno if we need to do something about, or better to just wrote it to corner cases ?
And interesting issue with which_icon seems so still present : when we have opened on the workbench pure WB window for let's say "RAM:", and then multiselected RAM: and let's say WORK: and dbl-click on it, then, Workbench check that RAM: is already opened, and didn't open a Filer on (that ok), but then, it opens another disk you select also as pure WB one :)
In other words, when original WB window opened on some disk, and you tried to open that disk and some other one at the same time, then, then WB check if window already opened, and returned to the way which broke patch's logic
Right you are. I was looking for a preferences setting, and completely missed the Workbench menu. Duh. Shows how much I actually use that menu.
@kas1e
Speaking of unused menus, the Workbench menu also has "Open Volume", which provides yet another way to open a Workbench window without selecting any icons.
As far as i test, and Filer and shell window both have same WFLG_WBENCHWINDOW and WFLG_BACKDROP flags.
Are you sure? When I use Scout to look at the flags for both Filer and Shell windows they both have WFLG_WORKBENCH set, but neither has WFLG_BACKDROP set.
Quote:
And btw this WFLG_BACKDROP is misleading by name : like, it's desktop's backdrop, but it's not:
True. But Workbench uses that mode for its background window, and it would be rare for any other program to open a backdrop window on the Workbench screen. So finding a window with those two flags set means it's most likely the Workbench background window.
Quote:
For me when i hit on the border of the window with opened WB drawer , it start to be active, and the selection from Workbench one unselects.
To be clear, I was saying that clicking the window border for an open drawer (not disk) window does not deselect any icons on the Workbench. The result is that the currently active window is not the Workbench background window, but there are still selected disk icons. So if you select "Open" from the menu those icons will be opened and any test that looks for the backdrop window to be the currently active one will fail.
Also, checking for WFLG_BACKDROP and checking ActiveWindow->BorderTop (or looking for WFLG_BORDERLESS) both fail if the Workbench background window is a regular window because the 'backdrop' option has been turned off. Scout reveals that the AmiDock window is borderless too, and so also has a BorderTop of zero.
Also, checking for WFLG_BACKDROP and checking ActiveWindow->BorderTop (or looking for WFLG_BORDERLESS) both fail if the Workbench background window is a regular window because the 'backdrop' option has been turned off. Scout reveals that the AmiDock window is borderless too, and so also has a BorderTop of zero.
Additional things you could check in Scout and if it's usable add the check(s) to wb2filer: - ActiveWindow->WindowPort (or UserPort, I don't know which one the Workbench uses) ->mp_SigTask == workbench_task (IExec->FindTask("Workbench") if there is no better way to get it). - ActiveWindow->Title && (0 == strncmp(ActiveWindow->Title, "Workbench", strlen("Workbench"))). I'm not sure, but even in backdrop/borderless mode it might set the same title as if backdrop is disabled.
Additional things you could check in Scout and if it's usable add the check(s) to wb2filer:
Thanks for the ideas. The title of the Workbench backdrop window is unset, so no joy there.
However, the window's UserPort's mp_SigTask is indeed the Workbench task. So perhaps that's the way to go- if the active window's UserPort->mp_SigTask is the Workbench task (ln_Name is "Workbench") then the new Workbench window is likely being opened due to some user interaction with Workbench, and not because of some other program asking Workbench to open the window.
That doesn't solve all the problems -- we're still assuming that the window being opened is for one of the currently selected icons, and that's not always the case -- but it's one more thing that can be checked in an attempt to determine what's going on.
That what i have returned when dbl-click on RAM disk on Workbench Desktop:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That when i in the shell hit "tab" (for command competition window to spawn):
Quote:
Caller->tc_Node.ln_Name is CON/con-handler 53.82 NW is NULL
That, what i have when type in the shell "wbrun ram:":
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = WinFrame 1 Process
That what i have when run Filer from AmiDock, and do "Open in workbench folder" from it:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Background CLI
That what happens when i hit "amiga+e" for command line window to spawn in the center of screen:
Quote:
Caller->tc_Node.ln_Name is AsyncWB - textinput process NW is NULL
That what happens if i use "Open Volume" from the workbench:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That what we have when select an Icon and choose "Open" from workbench:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench
That what happens if i select RAM:, and in the shell type "wbrun work:" while RAM: keep selected:
Quote:
Caller->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = WinFrame 1 Process
So, firstly good thing: this "UserPort->mp_SigTask" for sure good one!
Then, the thing i don't understand : So far, i didn't see anywhere at all that WFLG_BACKDROP is in place. Not when i click on Desktop's icons, not when i open any Workbench window. While all workbench windows have WBENCHWINDOW, but none of them have WFLG_BACKDROP.
Maybe simple WFLG_BACKDROP is not work for OpenWindowTagList() and this is wrong to check like this, and should be used WA_Backdrop instead ? At least in the Wiki i find this:
Quote:
Backdrop windows are created by specifying the WFLG_BACKDROP flag or the WA_Backdrop tag in the OpenWindowTagList() call.
And if i use WA_Backdrop instead, then, for every opened workbench window i do have together with WBENCHWINDOW and BACKDROP printf too, but there again no differences in this terms : all windows which have WFLG_WBENCHWINDOW also have WA_Backdrop
@All And i think we need to patch one more function : the one, which check if the workbench window is already opened or not.
Because as of now, we can be in this situation:
-- spawn original wb window by anything (wbrun from shell are ok), like for the RAM: -- now select on desktop RAM and second disk icon (work or whatever you have under the RAM one). -- dbl-click on any of them while both seelted.
Now, instead of opening just another disk by filer, it's instead open the same one we already opened and with keeping selected the selected icons do nothing, so i need to click another time, and then second disk opens and icons deselects.
I think issue there is that checking on the "if clicked disk already opened on screen or not" happens without involving of OpenWindowTagList(), so we just in mess a bit with our which_icon global flag : because it's 2 icons selected, but OpenWinowTagList() will be used just one time as the check on the "if window opened already" done not from OpenWindowTagList().
Have anyone an idea how to bypass this moment ?
ps. Btw, if we can find how Workbench checking on "if disk already opened on screen", we can then just avoid re-run of filer, and making it active instead.
Then, the thing i don't understand : So far, i didn't see anywhere at all that WFLG_BACKDROP is in place. Not when i click on Desktop's icons, not when i open any Workbench window. While all workbench windows have WBENCHWINDOW, but none of them have WFLG_BACKDROP.
You are checking the NewWindow->Flags, which of course never includes WFLG_BACKDROP for to be opened Workbench windows. Only exception maybe: If you disable backdrop in the Workbench menu (backdrop window closed, normal one opened) and enable it again (nowmal window closed, backdrop one opened). But I don't know if the Workbench works that way, closing and reopening the root window, or if it always keeps the same window and just adds/removes the border and backdrop flag.
To check if something was called from the Workbench backdrop window you'd have to use (ActiveWindow->Flags & WFLG_BACKDROP) instead.
To check if something was called from the Workbench backdrop window you'd have to use (ActiveWindow->Flags & WFLG_BACKDROP) instead.
You were right as always, yeah, now i can see that WFLG_BACKDROP is set for Workbench.
Do you aware of any way, how i can dereference when icon on the workbench selected (so active window is workbench) and then i hit "amiga+e" , and type there "wbrun something:", and while icon is selected on workbench, it's "workbench", but i need to detect somehow that with this "amiga+e/wbrun" combo it's not usual "click on workbench's desktop icon".
Im not sure if it possible to trace a command from which OpenWindowTagList() were called ? Because when we do "amiga+e", all i have is :
Quote:
Task->tc_Node.ln_Name is AsyncWB - textinput process NW is NULL
So far looks good, but then, when i type there "wbrun ram:", it then:
Quote:
Task->tc_Node.ln_Name is Workbench It's WBENCHWINDOW ActiveWindow->node->ln_Name = Workbench WFLG_BACKDROP!
The title of the Workbench backdrop window is unset, so no joy there.
Also, it's quite possible (and common) to have a volume with the volume name "Workbench:", and if you open that in WB, you get a window with the title "Workbench" - is that a problem you guys haven't considered yet?
So, firstly good thing: this "UserPort->mp_SigTask" for sure good one!
Yes, it looks like we can pretty reliably detect whether we want to hijack the OpenWindowTagList() call and open a Filer instead, or whether we want to let the window open normally.
The problem is still in knowing which disk we want Filer to open. We still have to assume that the window is being opened for one of the selected icons, and we know that's not always the case. What we really need is a way to know what disk or drawer Workbench is trying to open the window for, and we don't have any good way to learn that.
Some clues might come from the WA_Title tag of the window to be opened, if Workbench sets the title that way and doesn't wait until the window is already open to set the title. But even if the tag is present, the window's title has a number of obstructions to easy use:
- There's bunch of other stuff in the title besides the name - The trailing colon is removed from the name, so we can't readily tell disks apart from drawers (someone could have a drawer named "Work") - If it is a disk, the name is that of the volume and not the device ("RAM Disk" and not "RAM:"), and the volume name can be set to anything by the user - The path is stripped from the name; you could have more than one drawer with the same name that differ only in the path, and we can't tell them apart
The last one wouldn't matter if we could reliably tell disks apart from drawers, since we don't want to hijack drawer windows. But it's certainly possible that someone could have a drawer named "RAM Disk" somewhere, and based on the window title we couldn't tell that apart from the actual RAM disk.
Btw, if we can find how Workbench checking on "if disk already opened on screen", we can then just avoid re-run of filer, and making it active instead.
I imagine Workbench has internal data that it uses to keep track of what windows it's opened, so if you try to open the same window again it just activates the existng window. We don't have access to that data, so there's no easy way for us to duplicate that functionality.
Of course, if we open a Filer instead and pass NULL back to Workbench then it thinks there is no window open for that disk, so it will try to open it again if you ask it to.
The last one wouldn't matter if we could reliably tell disks apart from drawers,
That's no problem since drawers only have the drawer name as window title but disks additionally "x% full, y GB free, z GB in use". Only problem that it's locale based and different in different languages, but for example checking if there is one '%' and at least two ',' in the title should work for most languages. Even that doesn't always work, for example if someone has a drawer with a name like "abc 1%, 2, 3", but I guess you can ignore such rare cases.
That's no problem since drawers only have the drawer name as window title but disks additionally "x% full, y GB free, z GB in use".
That occurred to me as well shortly after I posted that reply. If the window title doesn't have the extra verbiage then it's a drawer, so just pass it on to Original_OpenWindowTagList() to become a Workbench window. If it does have the extra verbiage then extract the name, append a colon, and pass it to Filer. That's it. No need for the selected icon list or which_icon.
The devil is in the details though, and as you noted it won't be simple to reliably extract the name from the window title in all cases. And it's moot if Workbench doesn't use WA_Title to set the initial window title. So I guess it's over to @kas1e to test that.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
.