Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 20 of 20 total
Thread Banner / Paging Strategy
Mon, Aug 10 2015 4:15 AMPermanent Link

Mark Brooks

Slikware

Avatar

Uli Becker wrote:

>>Mark,
>>I remember there was a pretty detailed discussion about that. Unfortunately I can't find it. Do you remember it?
>>Thanks Uli

Hey Uli

I can't find this either, however here's a brief overview that may help:

The mechanism uses the hash part of the app URL i.e. the bit after the app URL that starts with a #. For example <URL to my app>#<some other stuff here>. The key thing here is that modifying the # element of the URL does not refresh the browser page, however it does trigger a "hashchange" event that you can trap AND it does get stored in the browser history, so you can use the "back" and "forward" actions.

To trap the "hashchange" event you can use the SetWindowEventHandler procedure from WebDOM. You can also remove your trap by using ClearWindowEventHandler.

Now, you can use your own nomenclature for the text that forms the # element of the URL, so the opportunities become quite interesting. In this case I generally have a section called View=XXXX where XXXX is the name of a "view" in my app. For example, to display the "Home View" I can simply set the URL to:

<URL to my app>#View=Home

This will trigger the "hashchange" event, which I'll have trapped. I can then examine Window.Location.Hash and determine which "view" to show in my app. Essentially this means which form to show. If the user then clicks something which should take them to the "User View", for example, I can simply set the # myself to:

<URL to my app>#View=User

And the trap will again be triggered so I can take the appropriate action. As an added benefit, clicking "back" in the browser will then change the URL back to the one targeting the "Home View" but without reloading the app. Very cool and very nice for the user.

If you wish to pass some further information to a "view", for example an Id that the view may require, then you can easily do so via a second parameter in the # like this:

<URL to my app>#View=User&Id=43

In this way all navigation within the app is handled by simply changing the # and the browser history is created accordingly. Furthermore, the user can save a URL and revert to it directly as and when required.

I have created an elementary EWB2 non-visual component to encapsulate this behaviour and a TForm descendant that reacts automatically due to a new property called its ViewName, however this is not quite ready for "public consumption" yet. As soon as it is I'll post.

As an aside, I think this functionality is so good for EWB that Tim might even consider including it within the framework as standard. It works extremely well well in many "multi-view" scenarios and users are immediately at home with view navigation within the app.

Hope this helps. Let me know if not clear.

Cheers
Mark
Mon, Aug 10 2015 4:32 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

I like this idea.
Mon, Aug 10 2015 4:52 AMPermanent Link

squiffy

Telemix Ltd.

Avatar

Mon, Aug 10 2015 6:35 AMPermanent Link

Mark Brooks

Slikware

Avatar

Mon, Aug 10 2015 10:23 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< As an aside, I think this functionality is so good for EWB that Tim might even consider including it within the framework as standard. It works extremely well well in many "multi-view" scenarios and users are immediately at home with view navigation within the app. >>

Sure thing.  Any time someone wants to contribute code, I'll be happy to include it. Smile (with the proper credits given, of course)

Tim Young
Elevate Software
www.elevatesoft.com
Mon, Aug 10 2015 10:56 AMPermanent Link

Uli Becker

Mark,

thanks a lot for writing that in detail again. Very much appreciated.

Uli
Mon, Aug 10 2015 1:16 PMPermanent Link

Mark Brooks

Slikware

Avatar

Tim Young [Elevate Software] wrote:

>>Sure thing.  Any time someone wants to contribute code, I'll be happy to include it. Smile (with the proper credits given, >>of course)

Sorry Tim. I didn't mean to suggest that you use my code, just the concept because it's so powerful. You'll invariably find a neater way of handling it I'm sure, but I'll post my solution when complete just in case you need any tips Wink
Tue, Aug 11 2015 12:30 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Mark,

<< Sorry Tim. I didn't mean to suggest that you use my code, just the concept because it's so powerful. >>

So, you're saying that I *can't* use your code ?

Just kidding.... Wink

<< You'll invariably find a neater way of handling it I'm sure, but I'll post my solution when complete just in case you need any tips Wink>>

Absolutely.  I'm learning every day from everyone around me, and there's no stopping it. Smile

Tim Young
Elevate Software
www.elevatesoft.com
Tue, Aug 11 2015 12:35 PMPermanent Link

Uli Becker

Hi Mark,

> I can't find this either, however here's a brief overview that may help:

I still have to check it out in detail, but a small test project works
great.

Thanks again! Uli
Tue, Aug 11 2015 5:55 PMPermanent Link

Mark Brooks

Slikware

Avatar

Great stuff Uli
« Previous PagePage 2 of 2
Jump to Page:  1 2
Image