Hi Mark,

> Also, what browser(s) and OS(s) are we talking about here?

Chrome and IE 11 / Windows7 prof. 64 bit

Attached a small sample that produces the error here. Just click on the
button and then on the Backspace-button.

Hope you'll see it.

Uli

Uli,

You need to check the NumPairs property of the THashHandler since this will tell you how many pairs have been parsed i.e. if this number is 2 then you can safely access Names[0], Names[1], Values[0] and Values[1]. In your case, the hash returned from the browser is '' (blank) and NumPairs is 0 (as you would expect) so you cannot access Values[0] in your OnChange handler.

Hope this makes sense?

Mark

Mark,

ok, that makes sense. I was misled by your posting:
<< Not sure you should ever get that event with no hash? >>

Anyway the component works very well - thanks again for sharing it.

When using this stuff in a real application there are some problems
solve though. E.g. when you open a form (adding the hash) and close it
manually. The next time you try to open the form by using the code in
the OnChange event of the hash component, nothing will happen, because
there is no hash change fired.

To avoid that you have to add another pair (e.g. home) to the component.

But generally that's a big improvement for mobile devices. (It often
happened to me that I tapped the Back-button of my tablet and the
application was closed.)

P.S. It took me a while to find out why the "Backspace" button worked on
some forms but not on others - the reason was that the focus was on a
TEdit field.

Cheers Uli

Uli

I normally define a number of "views". Each view is represented by a form. I would always include a "Home" view and a blank hash would go to this as would a View=Home pair. Going to a view normally means showing the associated form and hiding all others i.e. I would not use modality.

Cheers
Mark

Mark,

playing around with the hash-handler: how can I "delete" the
hash-history? IOW: I don't want the Back-Button to loop trough all
opened forms: after returning to the main form (home) no further action
should take place.

Thanks Uli

On 8/31/2015 12:54 PM, Uli Becker wrote:
> playing around with the hash-handler: how can I "delete" the
> hash-history? IOW: I don't want the Back-Button to loop trough all
> opened forms: after returning to the main form (home) no further action
> should take place.

I have not had a chance to play with this yet but i'd imagine you'd need
to just update the current hash to initial hash you started with on main
form (and ignore the "hash changed" event that fires).

Raul

Raul,

> I have not had a chance to play with this yet but i'd imagine you'd need
> to just update the current hash to initial hash you started with on main
> form (and ignore the "hash changed" event that fires).

At the moment I have no influence what happens when I press the
Back-button on a mobile device. It seems to loop through all "recorded"
hashes.

Actually I don't understand the whole thing completely - will have to
study the basics.

thanks Uli

On 8/31/2015 1:15 PM, Uli Becker wrote:
> At the moment I have no influence what happens when I press the
> Back-button on a mobile device. It seems to loop through all "recorded"
> hashes.
>
> Actually I don't understand the whole thing completely - will have to
> study the basics.

As i said this is purely theoretical at this point but assuming your
component is called "hashhandler" you should be able to do something like

hashhandler.clear;
hashhandler.update;

when you're back on main form and want to get rid of hashes there.

You might want to add a default has back there using "hashhandler.add"
before calling update also.


Raul

>>Uli Becker wrote:

>>playing around with the hash-handler: how can I "delete" the
>>hash-history? IOW: I don't want the Back-Button to loop trough all
>>opened forms: after returning to the main form (home) no further action
>>should take place.

Hi Uli

That's a bit tricky because the component itself does not hold any history. It merely provides a very lightweight wrapper for the "current" browser hash value. The history is held by the browser itself. The upside is that this allows the back and forward browser actions to work nicely. The downside us that (AFAIK) you cannot zap the history since that would be a JavaScript security violation.

The hash element of the browser URL can be changed without the page (i.e. your app) reloading. In this way it is useful for navigation purposes and also for passing additional information to pages (i.e. your app) that can be used in a particular context. Additionally, users can save the URL and return to the same point in your app later OR you can email them a URL that takes them directly to a certain point in your app.

I think that if you're going to use the browser hash for navigation within your app then you should ensure that each of your app "views" are "stateless" i.e. a user could visit them directly (albeit with an additional hash parameter to provide context). Typically, these would therefore not be modal dialogs.

Hope that makes sense.

Mark

Thanks Mark and Raul,

I begin to understand, what's actually happening with the hashes. Before
I'll use it in real application, I'll create a test application with
different scenarios and test everything out.

Cheers Uli