Thanks. I will investigate this soon.

(I really like the code sharing between users, it is very nice here. I must put
updated versions of my general code up sometime.)

/Matthew Jones/

>> Thanks. I will investigate this soon.

No worries. Let me know if it doesn't make sense

>> I really like the code sharing between users

Ditto. Very useful.

Okay, I've had a moment to play with this. Shows it all nicely, but I'm not sure
how practical it is. If I press the Back button it is detecting the change without
leaving the page, but how does that help me? When I click back enough, it does go
back to where I started.

I guess the key is that I have to put a #page=shop the moment someone visits, and
then as they navigate make it #page=account or whatever. Then the Back will trigger
this event, I move to the appropriate page, and it works out. Hmm, that would be
viable.

Is there a reason it has to be pairs? Can I not just do #shop or #account? And why
does your code not use the TStringList.Values[] to store it?

I like this overall though, I'll adopt it. Thank you.

/Matthew Jones/

Matthew Jones wrote:

> Is there a reason it has to be pairs? Can I not just do #shop or
> #account? And why does your code not use the TStringList.Values[] to
> store it?
>
> I like this overall though, I'll adopt it. Thank you.

Okay, I added it to the shop code, and you can indeed just keep it as a
simple key, and then you can use Back to go back to the previous page
using that key alone. Really nice. Thank you very much. I shall deploy
this now...

--

Matthew Jones

"Matthew Jones" wrote:

>>Okay, I added it to the shop code, and you can indeed just keep it as a
>>simple key, and then you can use Back to go back to the previous page
>>using that key alone. Really nice. Thank you very much. I shall deploy
>>this now...

Hi Mathew
Glad it worked ok for you.
I use View= because my app has LOTS of different pages, all of which are navigable, some of which are "views" and others not. It obviously doesn't matter what mechanism you choose.
Have a good weekend
Mark

Mark Brooks wrote:

>>Do you have code for EWB to do it? I'll give it a go if you have.

SO SORRY for the delay, but hope this makes sense

// Call this in order to trap changes to the "hash" part of the URL

SetWindowEventHandler('hashchange',TrapWindowHashChange);

// Code a bit like this will form the trap [...]

I've been trying to implement the browser navigation system suggested in this thread in EWB1. However, I haven't been able to trap the window hash. The project compiles OK but navigation doesn't work as intended. I think I am going wrong with the creation of fWindowHash. I would be grateful if anyone can point me in the right direction.

StewCam wrote:

<<I've been trying to implement the browser navigation system suggested in this thread in EWB1.>>

I'm assuming you're implementing in EWB2.  I had some difficulty getting this to work too.  No guarantees, but the attached project has the hash navigation working, and the browser back button is functional.

-Jim

>>Jim Gallagher wrote:
>>I'm assuming you're implementing in EWB2.  I had some difficulty getting this to work too.  No guarantees, but the >>attached project has the hash navigation working, and the browser back button is functional.

Thanks, Jim. This is working for me in EWB2 (my previous attempts were in EWB1). Much appreciated.