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 :)
@balaton Thanks ! Fixed/changed almost everything, except that with asnprintf i only add check that it's not <0 , because i can't check for "full string" , as paths differs, and maybe someone willing to run not just filer, but some other binary instead (like AmiDisk or so:) ).
@msteed I think Balaton mean to shift setting of the value just before calling of command, to avoid in-the-middle multitasking issues as much as possible. And i set this value inside of OpenWindowTagList() as this one already check on the Workbenh task, on the ICON type, and so on.
Quote:
1. If you click on an icon and then select 'Open' from the Workbench menu you get a Workbench window, not a Filer.
Yeah, that seems to happen because when you click on icon, and then hit RMB, and choose "open" the mouse cursor is out of the icon, so, checks inside patched function fail => run as before.. Probably we need somehow to change the code to be not just WhichWorkbenchObject() as it now, but somehow tell the function (if possible) that "if highlighted, and does not matter where clicked"). If possible of course ..
Quote:
2. I figured a good torture test of the DisplayBeep() patch would be to shift-click a number of icons, then shift-double-click the last one, to open all the icons at the same time. DisplayBeep() worked fine, but all of the Filers that opened were for the last icon, the one I double-clicked.
Mmm.. right.. Issue there, that to take a path to which icon belong to, i use that WhichWorkbenchObject() again, which works for the icon you clicked on seems so (at least by default).
So we need to find a ways how to tell WhichWorkbenchObject() to take path just when icon highlighted and not when mouse cursor over it or clicked at. This will fix both issues for us then. Have any idea maybe ?:)
@All
New version:
Quote:
-- build with -Wall and -O3, later of which made binary be smaller on 1kb -- made a changes/fixes following Balaton's coding style suggestions (kudos for help!): -- made struct Task to be local to Patched_OpenWindowTagList() -- cleaned and simplify ctrl+c loop by get rid of unuzed vars and shifting printf out of ctrl+c check-loop -- minimize multitasking risks of calling DisplayBeep() out of our hack -- added error checking for Task creatiog and asnprinf() result -- use sizeof(..) with WBOBJA_FullPathSize to avoid future's potential issues when code grow -- fixed missing return in Patched_DisplayBeep()
It's imho too small/easy hack which anyone who have 68k can make if need it, but just in case: i put source to archive, so all what the one doing this need to do to for 68k version of it, is to replace SetMethod() by SetFuntion() and i do not know if OS3.x have WhichWorkbenchObject() support with all this types/paths, etc, so maybe need to change something for this part too to make it works on os3.x.
@All New version:
-- hijack Intuition->DisplayBeep() as well, to disable wb-bar blinks after Filer's run and original OpenWindowTagList() returning NULL (thanks msteed for idea) -- updated readme to be in sync
In other words, you have no needs to disable prefs:sound alerts now, and can keep it working.
Not sure if it correct that firstly we have widnow/screen addresses ok, and then another time with 0x0 ?
But then, i tried to run this warpsness on my Pegasos2 (which had Radeon9250, so no modern RadeonHD or RadeonRx) : and it also gives me black screen ! But, this time i don't have window 0x0 and screen 0x0 at the end of debug output, but still black screen.
What is common between all my os4 machines, is that they all up2date and use latest graphics.library and co. Maybe your OS4 aren't up2date and this can be a difference between your and our setups ?
Here is a download link to the latest version with the changes mentioned above.
Feel free to test, but i doubt it will solve the black-screen and border issues.
Yeah, full-screen still same black :( Through list of modes now looks more clean and better when you choose screenmode. Just strangely black screen .. Like, buffers not flipped, or something. Or some tag enabled/disabled.
PS. Btw, can you (if you have time) add also window mode x3 and window mode x4 ?
-- few logical fixes: replaced 3 calls of asprintf() by one, ditch unused vars, shift parsing of argv (thanks Balaton) -- now hijack only root (WBICON) volumes, so you still can continue to open pure WB folders from Filer or via "wbrun" tool as before
@all Have few more ideas, but not sure if they worth of it or not:
1). create a commoditie. Not sure if there needs for, and if, not sure if plain binary need to keep, or ditch in favor of commoditie ?
2). currently, all workbench drawer calls are patched, i.e., not only when you hit on the "root" ones, but also if you will for example do "wbrun xx0:drawer". The same when you will try to "open in wb folder" from filer. Maybe it worth to hack only ones which on desktop ? Like, parse the path, and if it contains "/", it means more than root volume, so don't hack it, and only hack it when it has only ":" at the end. Is it worth at all ? At least for me, a bit suck when i tried to "open in workbench folder" from filer, and it opens instead another filer :)
@All Created a small hack (thanks Petrol for idea) which patch Intuition's functions via SetMethod() to allow transparently run of the Filer binary pointing to the given partition on Workbench's Desktop instead of original Workbench windows. Things like "Open Workbench" in Filer, or "wbrun" from shell / asyncwb work as before and open for you original WB window.
There is how it looks like currently:
Check this out, suggestion, and bug report are welcome of course:
Hitting "ctrl+c", will clean the patches up and exit.
If you like, you can run it from User-Startup as well, just by adding (as example):
RUN >NIL >NIL: work:wb2filer/wb2filer system:utilitites/filer/filer
Edited by kas1e on 2023/11/24 6:45:23 Edited by kas1e on 2023/11/24 6:46:48 Edited by kas1e on 2023/11/25 10:10:24 Edited by kas1e on 2023/11/25 10:10:50 Reason: version update Edited by kas1e on 2023/11/27 8:22:53 Reason: version update Edited by kas1e on 2023/11/30 9:02:46 Reason: version update Edited by kas1e on 2023/12/1 13:14:29 Reason: version update Edited by kas1e on 2023/12/1 13:14:54 Edited by kas1e on 2023/12/7 11:22:42 Reason: version/video update Edited by kas1e on 2023/12/7 11:23:11 Reason: revsion/video/text updated Edited by kas1e on 2023/12/14 3:41:26 Reason: version update Edited by kas1e on 2023/12/17 10:40:01 Reason: version update Edited by kas1e on 2023/12/17 10:41:39 Reason: updating Edited by kas1e on 2023/12/17 10:41:54
@All Can somebody point me out how correctly block the patched openwindowtaglist, so it only does what i need, and then do nothing (and not open workbench window). So far i tried to return NULL instead of original, but then while window not opens, it "blink" the title bar.
Through found some moment : when one window opens on top of the previous ones, and the mouse cursors are over both of them, then i have empty string returned. While i were expected to get it from the active window.. But maybe there another flag for ?
Edited by kas1e on 2023/11/24 3:13:40 Edited by kas1e on 2023/11/24 3:19:19
Does DrawerGenie get such path too? Then you can look in its sources how.
DrawerGeniue written by Daedalus on BlitzBasic, he already answer in the previous post how he do it :) (arexx interface)
Quote:
You posted that DG does "SetMethod()" in these functions:
It wasn't about DG, but about Dopus5 :) Its list of patched functions for Dopus5 when it's in workbench replacement mode. Yeah, will check, maybe it will bring some idea as well
Maybe insde wb_lib or whoever do such task to open wb drawers/windows uses a "own" struct with some data and one is STRPTR for fullpath.
Question is where is it :)
Quote:
I used the ARexx interface to get the name of the currently active window,
As one more idea .. but not very "system" ones imho :) Anwyay, thanks for idea.. But why you need to check dimensions ? Just for sake of double-checking ?
@All When we click on icon, it involves surely some more functions and not only "openwindowtaglist()", but maybe something else which did containt "full path" in structs ? It should be somewhere all in all..
@All Is there any correct way to know the full path of the opened workbench window ? So far all i find is *Title string in the window's structure , but i am sure there should be something better to get this information from a workbench window ?
in textmode window (as your grab) the titles headers are created as CUSTOMGADGET and seems it is just after window is opened/created.
So it's not part of a window then, but of a border ? And then, increasing size, clone gadgets, add our new one to them, and upload them back may work then.
@Petrol Quote:
Just a suggestion but wouldn't it be simpler to write a small commodity that simply open Filer or any other similar tools directly to the drive/drawer you want to open by double click?
We mostly want to do it for own pleasure and technical interest, and to have something which we fully understand, and which small as possible and still the same old workbench which many of us still love :)
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
