Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[james666]

I made a small hack to lib.s that I think fixes the file request bug.  If you enter "/" as a file name it now takes you up one directory level without appending garbage to the path name.  Source code and reassembled amospro.lib are attached.  My edit is on line 18848:

Code: [Select]

***james666 edit **************************************************************
* Check whether new filename is just a "/" and go up one directory level if so.
cmp.b #"/",(a0)
bne.s .Lp2
bsr Fs_Parent
rts
*******************************************************************************


[SamuraiCrow]

Sorry I haven't replied until now.  Maybe after BruceUncle sees this there will be more to say.

[bruceuncle]

Hey, good to see you back james666.  That's a simple and elegant fix.  I'd never considered using the existing parent directory routine.
So Hungry Horace, does that do the job?  And do I have your permission james666 to include this in the V2.10 release?
I have also fixed the DBL in the resource file for the file requester so you can use a wheel mouse to scroll it.  Assuming you're running that little program that enables a mouse wheel on an Amiga (is it called freewheel? I'm not on my PC to check).  Also looking at scrolling the editor using a wheel mouse.
I'm severely limited in how much time I can spend sitting until my back heals up fully.  So PC time pretty sparse for a while (hence Tapatalk).  But I'll check it all out next session.

Sent from my Lumia 800 using Tapatalk

[SamuraiCrow]

It occurred to me that the patch should check the length of the string in case it backs out of the current directory and into another.  Or even backs out multiple times.

[james666]

I've attached a slightly refined version based on SamuraiCrow's feedback.  It should now be able to handle multiple /s and go forward again after backing out.  For example if you start at dh0:amos_pro/productivity2/wonderland/, typing "//productivity1/" will take you to dh0:amos_pro/productivity1/

The patch is now moved a little further upstream and starts at line 18045

Code: [Select]

Fs_Return
* Fs_GetName gets the filename input and splits it into
* relative path (pointer in a0) and filename (pointer in a1)
bsr Fs_GetFName
tst.b (a0) Si pas de path >>> OK!
beq.s Fs_Ok
movem.l a0/a1,-(sp)
bsr Fs_Store
bsr FsI_SliStore
movem.l (sp)+,a0/a1
; Enleve le path du nom
move.l a0,-(sp)
move.l a1,a0
bsr Fs_NewName
move.l (sp)+,a0
; Compute le nouveau path
.Skip move.l a0,a2
move.l Name1(a5),a1
.Lp1 move.b (a2)+,d0
beq.s .Plus
cmp.b #":",d0
bne.s .Lp1
clr.b (a1) Un nom de device=> RAZ path

***james666 edit **************************************************************
* Check if new pathname begins with "/" and go up one directory level if so.
.Plus cmp.b #"/",(a0)
bne.s .nd
move.l a0,-(sp)
bsr Fs_Parent
move.l (sp)+,a0
addq #1,a0 *check if we have a repeated "/"
bra .Plus
.nd bsr Fs_NewDir *update the directory with new relative path
rts
*******************************************************************************


[Hungry Horace]

nice sounding fixes guys! Cheers for this

So when will be expecting to see the next beta for 2.10 ?

[bruceuncle]

So when will be expecting to see the next beta for 2.10 ?

V2.10 is still very much a collection of bits and pieces at this stage.  But if I exclude some stuff in the editor that needs changes to the config (ones that can't be done with Editor Configuration editor).  And if people are prepared to edit in a couple of new error messages (ones that can be done with Editor Configuration editor).  Then I should be able to put out a simple "replace the following files" beta.  I won't release anything new to do with the Help in that release as I'm now completely sold on that alternative method, discussed elsewhere, that allows extension help files to graft in seamlessly.  (See, all that pouring over the sources in hospital was worth it!  )  Having thought it all through in great detail, it's the only way to go.  And better to do it now whilst still in the database as the switch to tokens for the keywords is simple there (that's what relational databases are for!).  So minimal changes needed for maximum gain.    I'd eventually like to see an AMOS utility so anyone can do it.  But that's just wishful thinking.  I am determined to concentrate solely on the V2.10 final release so no more distractions!

But please bear in mind that I'm still far from "normally" active yet, so my time at the keyboard is severely limited for the next few weeks.  I'm only allowed to sit for 20 to 30 minute periods a few times a day and some of that is taken up eating food.     So please don't expect "instant action".  And don't think it doesn't frustrate me too!  It will be a good few weeks before I'm more fully recovered.  It was a bloody big operation!

[bruceuncle]

Hang on a minute.  Hang on a minute.  Before you get carried away, I've got a couple of objections:

• The field this stuff is being entered into is used for a file name.  I could just about live with the single "/" to mean gimme the parent directory.  But taking it any further is starting to make it look suspiciously like a command line field.  Just where do you stop?
• This doesn't actually fix the bug that Hungry Horace reported!  That bug relates to the path field above the file name field.  Try putting "//" at the end of a path and you'll see what he meant.  It gives the parent directory okay but the path name in the list remains forever with the "//" at the end.  So it looks a bit daft in the directory history list.  But at least Hungry Horace is correctly entering it in the path field.
  
  I'll look into using keyboard shortcuts for the buttons in the DBL for the dialogue.  I can't use obvious ones such as [ctrl]+[P] for the Parent button as the cursor is in the file name field when the dialogue opens, so the Interface language will take it as input there.  The user would need to tab out of the edit fields for shortcuts to work - which is far from intuitive and not easy to see on screen.  I'll try using function keys as it does action the arrow keys and mouse wheel codes whilst the cursor is in the edit field.  So maybe non-printing keys would work.  Simply [F1] for the top button, [F2] for the next, etc.
  
  Failing that, we should at least clean up what happens if the user does type "//" at the end of the path and get it to display properly.

I'll have to wait until my next PC session to try stuff out as I've come to the end of my "sitting limit".  So bear with me...

[james666]

I think the glass is half full.

1. The filename field in the original AmosPro file requester already accommodates a relative path, including multiple /s at the start.  My patch simply stops any /// being messily appended to the directory field - no other change in behaviour.  (This is also consistent with the way "File" field behaves in the "proper" AmigaOS file requester.)

2.  I did not consider that the // might be entered directly into the directory field.  I would not say that it's more "correct" to do this - just a matter of personal preference.  As you can tell, my habit has always been to use the filename field exclusively.  However, I do agree that the directory field behaviour needs to be fixed.  It should be possible to do this so it takes care of // in the filename input at the same time, but it will need a slightly more complicated patch than my original 7 line hack.

[Hungry Horace]

I'm confused now, lol.
Maybe I'll do a video of the bug later...

I think it was the file path field though..: as James said, like the Amiga file system.... Basically, it's whichever one messily adds the / onto the path rather than behaving like you have clicked the "parent" button (which is the habit I have forced myself into)


P.s. Bruce , I realise you are far from recovered and only meant in jest about the 2.10 beta, simply because there are a few fixes flying about now and it would be nice to have them all "committed" to something we can try out..... 

[bruceuncle]

Sorry.  I didn't intend to sound mean about the stuff already done here.  I was just amused that the actual bug hadn't been fixed  .

I've attached a drop-in replacement for AMOSPro_Default_Resource.Abk.  This is from the V2.10 release.  As usual, back up your existing copy just in case...  This version allows a wheel mouse to be used for scrolling.  You need some software to recognise a wheel mouse on an Amiga, I use WheelMouse (attatched).

Following these discussions, I've also added shortcut keys for the buttons.  As explained in a previous post, these can't be intuitive ones like [Ctrl]+[P] for [Parent], so I've just used the function keys.  But you may find them useful.  Let me know.

The DBL source for the changes is attached and, as it's easier to read chroma-coded, there's a PDF of the listing. 

There's also a zip of the DBL Editor which I posted ages ago but should really go in the Downloads section under AMOS Factory / Development.  I know no one else will probably use it, but there's a heck of a lot of DBL used for the AMOS interfaces.  So I use it a lot for analysis of the original code and it will get quite a work out for some of the enhancements I have in mind.

Talking of enhancements, although I won't be doing anything with them until V2.10 is out, there's one for the file requester that will be dead easy:  I get fed up with the file requester always opening in the AMOSPro directory.  The code uses that directory by default and gets it from AMOSPro_Interpreter_Config.  When the requester gets a workout , the last directory visited becomes current, but this is all lost when you quit AMOS.  There's a spare slot in AMOSPro_Interpreter_Config at position 15.  I would like to use it for the user to define their own default directory.  The accessory Interpreter_Config.AMOS would need to have a screen added to allow the user to set this up (see, more DBL again  ).

The shortcut keys for the file requester are:

Shortcut Key	Button
[Return]	[OK]	existing
[Esc]	[Cancel]	existing
[F1]	[Parent]	new
[F2]	[Devices]	new
[F3]	[Assigns]	new
[F4]	[Sort]	new
[F5]	[Sizes]	new
[F6]	[Get Dir]	new
[F7]	[Store]	new

[james666]

OK - hopefully third time lucky...  The attached version should handle multiple // regardless of whether they're entered in the pathname field or in the directory field.  Every time one of them changes it's passed to a new FS_TidyPathname routine, which checks for // and strips out redundant sub-directories.

[Lonewolf10]

Wow, you've (bruceuncle and james666) been busy

Downloaded and will (hopefully) try at the weekend.