Scroll-less Portals

[LaRetta]

I've decided to post a working file which eliminates scrolls. I dislike them. In addition, many times it's difficult to restrict a relationship sufficiently and, if I need to sort the relationship or portal, or if there are a lot of related records, portal re-draw, find and sort can slow it down - particularly when jumping from one main record to another. Simply restricting the length of the portal doesn't restrict FM's need to find, sort and calculate the related set for display (and Lord forbid I have unstored calcs in the portal). Scrolls are simply ugly (sorry FileMaker). I believe clicking an arrow (jumping in groups by the total number of portal rows) is much quicker than scrolling (at least on Windows) and constrained relationships matching the portal length don't pop either.

I want to restrict my relationship to my portal to match the number of portal rows. This is what I've come up with. I am asking for ideas on improving the dynamics of it in any way. I would like to eliminate the need for script at all, but I've been unsuccessful in my attempts. I've tried creating a sequence in related, aggregate in related, and finally settled on ValueListItems() but I'm unsure that's the best way. I want this dynamic so I can use it on all my portals.

The demo is to provide a starting point of what I'm attempting. My needs are simple ... I want the best. And I have not achieved it yet. And I need help with that silly cSetNumber calc - it breaks. It must be easy but I'm missing the math logic of it.

I've been working on the functionality longer than I wish to admit. I stop working on it and just play with the colors - direct indication I've hit a thought-wall on it. And I know I won't be able to sleep until I solve it. When I started to add a THIRD table occurrence, I knew I was getting way off track. I also confess to posting this in other forums because I'm going insane on it and need fresh perspectives. All ideas greatly appreciated. :

LaRetta

NoScroll1.zip

[SlimJim]

This is developing amazingly well. The problem with cSetNumber is that you should use Div not Mod in its definition. This gives the first set number as 0, if that is not OK then add 1.

[LaRetta]

Hi SlimJim,

I do use Div() in this file. Did you look at my original demo from my other post instead? This one is at least fully functioning except for the portal jump display, ie, Set _ of __ (where cSetNumber is used).

cSelectNumber is: Div(gStartRow; cNumberOfSets) + 1

Set to 20 rows, it jumps: 1, 2, 4, 6, 8. Bummer. I had been trying to use Mod() with it as well (even using Mod and Div together) because Mod() (according to FM Help), returns: Mod(Participants;TeamSize) returns 4 if Participants contains 40 and TeamSize contains 9. It seems I need to account for a remainder and if so, add 1, else don't. Are my lacking math skills showing? :

Also, in case anyone is interested, all of my tables have serials. But they are never contiguous (because of deletions) ... which is why I just can't grab a number series. I would need to either loop-set a serial first or (?). Using VL seems to address this problem.

LaRetta

[SlimJim]

Correct in your assumption. I was looking at the wrong example. So far as the other example is caused a second problem has crept in. The second argument in the Div of cSetNumber should be gNumber of Rows. The sequence you are getting is logical given that you are using 11 as divisor instead of 20.

[LaRetta]

Oh God, that's what happens when I rage on a problem until brain dead ... Absolutely correct thank you so much! :

Problem solved and file corrected!!

Well, I have a working scroll-less portal. Are there better ways of handling it? I also disconnected the redundant MainID=MainID from the new relationship because it wasn't necessary. DOH!

[LaRetta]

Comment just presented the perfect scroll-less portal here

It doesn't even need a global.

My Users will be tickled which tickles me to no end. The demo rocks!!! :

:yay:

[Lee Smith]

Which post are you pointing at. Yours or His on the previous page?

[LaRetta]

The one Comment posted, Lee. That's why I indicated that he rocked and he solved it for me! My last attachment is identical to his. I didn't make any structural changes to it - only deleted a few records which doesn't affect it one bit.

My original file is prettier though. It just wasn't as elegant. :

[Søren Dyhr]

couldn't you just post comments template here as well, it's a little confusing which is which!!

However if recordlocking in a served solution allows it would I mark the related records this way in a 10 line fixed portal:

Replace Field Contents [ theRelated::Marked; Replace with serial numbers: Entry option values; Initial value: 1; Increment value: 1 ] [ No dialog ] 

Replace Field Contents [ theRelated::Marked; Replace with calculation: Div ( theRelated::Marked-1 ; 10 ) ] [ No dialog ] 

knowing the max number of records is simple enough so it just a matter of locking to the marked field with integers from 0 to upperlimit.

--sd

[LaRetta]

Hi Soren,

I will check with Comment about posting his file. I didn't mean to confuse things. It might help folks here because they then won't have to wade through my driveling on the other site as well.

I considered Replace Contents[] originally but it can't be error-trapped for record locking, I believe. I was hoping that would change in 7 but I think the issue still exists. But regardless, why write to multiline or mark or paste when it's dynamic? And what if two Users want to view the same set? This is what has been bugging me and why I opted for VL written to global.

There are a few issues I'm still working out on it ... sorting, etc. ... but I want dynamic and want to figure the perfect solution for many portals. Then same arrow script attached to multiple portals (same script) will work also. I just finished attaching his solution to my Customers/LineItems! OMG. It cuts several seconds out of draw time even over my test file. Scrolling through Main records is instant! I can't wait to test it networked.

[comment]

I will check with Comment about posting his file.

I don't mind. Or simply, if you want, download the file.

[Søren Dyhr]

I considered Replace Contents[] originally but it can't be error-trapped for record locking

Yes thats what I said, it can be done differently though in order to cope with the locking ...but it's going to loose some speed:

If [ IsEmpty ( Get ( ScriptParameter ) ) ] 

     Perform Script [ "New Script"; Parameter: 1 ] 

Else 

     Go to Record/Request/Page [ Get ( ScriptParameter ) ] [ No dialog ] 

     Set Field [ theRelated::Marked; Div ( Get ( ScriptParameter )-1; 10 ) ] 

     If [ Get ( RecordNumber ) = Get ( FoundCount ) ] 

          Exit Script 

     End If 

     Perform Script [ "New Script"; Parameter: Get ( ScriptParameter )+1 ] 

End If

...eventhough the prevention of the recordlocking haven't been introduced in the script yet.

--sd

[Søren Dyhr]

Hi Michael

There is one catch to it, what if the relation is sorted with buttons over each coloumn in multifield portal via a GetField( defined sortorder ...ValuelistItems sorts only the way defined in the prefs???

--sd

[comment]

This was NOT intended to be a demo of a general method.

The original requirement was to have the records appear in reverse creation order. It is still possible to change the sort order by playing with the valuelist definition - but not dynamically.

[LaRetta]

To everyone,

I'd like to ask a question just so I understand this better, because I just tested Soren's method (even without record locking) and my file is still much faster in a large related set. Did anyone take the time to review my method besides SlimJim? My file removes the problems with sorting, record locking, missing serials and speed issues that have been raised. Can you give me comparisons here? I would like to know where my logic is weak when deciding which method I will use to solve a problem.

I just tested them all on a larger related set. comment's solution is the fastest, beating my file by 3 seconds. My method is next, beating Soren's suggestion (without error traps) by 2 seconds. A standard full-related relationship takes 7 seconds in my test (to find the related, sort and then display them). I've learned (from Comment's file) to improve my calcs, but I'm interested in critique of the functionality I devised.

When approaching a problem of this type, these types of comparisons (and understandings) will come in very handy. I would appreciate the input on it. This is a great opportunity to learn ... but only if I ask these questions. Don't worry about me ... I have no pride ... only a desire to understand. Please review my original attachment here and give feedback on it, if you all would be so kind. :

Regardless of the method implemented, easing the strain on a sorted portal (by limiting the relationship) appears to be very worthwhile; at least in these types of portals. To be able to even shave ONE second off AND eliminate scrolling at the same time, has sold me on the concept. I would also be interested in any other tests others may run on it.

LaRetta

[Søren Dyhr]

But for LaRetta is the packets send over the network that bothers her:

Simply restricting the length of the portal doesn't restrict FM's need to find, sort and calculate the related set for display (and Lord forbid I have unstored calcs in the portal).

Which is what Debi Fuchs have spend some times investigating on a previous version ...the survey establishes that when opening a new layout it invokes of the index for all the portals to be transported to the control of the scrollbar attached.

http://www.aptworks.com/downloads/presentations/PacketWatchingPres_v2.PDF

I think the problem here is horror vacui ...the fear of being an inadequate artisan, that forces some to act entirely against guidelines of Albert Harum-Alvarez - by doodling every corner of the layout by going ons ...only to discover that the rendering is terribly slow and the extra knowledge gained from a stuffed layout differs only slightly from a targeted and dedicated one - if not even counter productive!!!

http://www.smallco.net/RestrainYourself.pdf

Might there be another solution to the problem, by the feature to make a new window in GTRR when attached to a button???

Personally am I pretty impressed with the datepicker tecniques from:

http://www.spf-15.com/fmExamples/

--sd

[comment]

This is what happens when the conversation is split between two threads on different forums...

In the original thread I said:

... In theory at least, you could take the value list of serial numbers, and extract the last 20 values. I wonder how slow this would be. ...

So at least in theory I agree with your reservation. In practice, I would have to create a huge file and test it over a network (that I don't have), so I am happy to leave the testing to LaRetta.

[Søren Dyhr]

My file removes the problems with sorting, record locking, missing serials and speed issues that have been raised.

No where is the point in pressing the button several times to get a name say Xerxes which intutively is somewhere beyond the middle probably closer to the end, since there are likely to be a herd of Smith's - a button for reverse sortorder is very much in demand so they show up after just 1 perhaps two strokes.

Other means to slice and dice that data might be more appropriate??? Read what Albert Writes in his .pdf

--sd

[comment]

There is one point that perhaps needs clarifying.

There are two relationships here. The AllRecords relationship remains static during the "scrolling". Once the full ID list has been assembled, there's nothing to do except to extract say 20 ID's for the second relationship. This should be very fast, I think, and the second relationship only requests 20 records at a time - so that should be fast as well.

The issue that I was talking about (and you need to read LaRetta's original description of the problem) is what happens when a record is removed from the AllRecords relationship. This necessitates recomputing the full ID list, and that might take a while.

[Søren Dyhr]

This necessitates recomputing the full ID list, and that might take a while.

Unless it's done this way, it observes changes in sortorder as well as dissapeared records... it's not going to tamper with others record locking.

The unsolved issue here is the tampering with the clipboard ...which is pretty easy and not worth mentioning here!

My subscript is using page 11 of this magnificiant .pdf-article:

http://www.onegasoft.com/tools/fastsummaries/FastSummaries.zip

...only it's being condensed severly due the use of scriptparameters.

--sd

Restricting.zip

[comment]

Yes, you could use Copy All Records just as well. I don't know how long it takes to omit the amount of records LaRetta has, but the principle is sound, and you could also sneak in a Sort in the process.

Note:

Script parameters are a version 7 feature. If you're using version 7, you can use Omit Multiple with a calculation, so the elaborate 2^0, 2^1... method is no longer required.

[Søren Dyhr]

Meanwhile did it occure to me that Edoshins algorithm could be tightned up further, thanks to script paramters:

If [ IsEmpty ( Get ( ScriptParameter ) ) ] 

	Perform Script [ "InitialOmits"; Parameter: Int(Ln ( Restricting::SetPointer ) / Ln ( 2 )) ] 

Else 

	Go to Record/Request/Page [ First ] 

	If [ Mod(Int(Restricting::SetPointer/2^Get ( ScriptParameter ));2) ] 

		Omit Multiple Records [ Evaluate(2^Get ( ScriptParameter )) ] [ No dialog ] 

	End If 

	If [ Get ( ScriptParameter ) = 1 ] 

		Exit Script 

	End If 

	Perform Script [ "InitialOmits"; Parameter: Get ( ScriptParameter )-1 ] 

End If 

...and by it save unnessersary recursions, because you exchange between bases of one logarithm into another by:

Log(x)/Log(2) ... and here is it importan to know how long the binary word is for Restricting::SetPointer without the leading zeros.

--sd

[LaRetta]

The AllRecords relationship remains static during the "scrolling". Once the full ID list has been assembled, there's nothing to do except to extract say 20 ID's for the second relationship. This should be very fast, I think, and the second relationship only requests 20 records at a time - so that should be fast as well.

This is exactly why I wanted to use a second relationship restriction. Well. I have MANY more questions. Surprised?

Restricting a relationship (regardless of the current burden on a portal, Soren) is powerful even if it saves only one nanosecond. I too use buttons for sort and filter purposes to assist Users; I will not argue that point. But buttons AND a scroll? Why waste space? If User must click a button, don't ask them to then scroll also!!! And sort buttons do not limit the relationship (thus still slowing draws) and, since the relationship is not restricted, scrolling still needs to occur. I too provide alternate windows or layouts quite frequently. But I refuse to throw the baby out with the bathwater. Instead I will solve the problem if possible.

Simply, if my tests prove it can be efficient (and so far they do), I will use it. A lot. Because design time is far outweighed by the time-savings to Users. Example: Redraw takes 3 seconds x 25 hits a day across a network x 5 days/week x 52 weeks/year. You do the math (it's not one of my strong points). How long would it take a Developer to implement (particularly if it is worked down to a standardized pattern using 7's power of script parameters, re-usable scripts, and table occurrences)? :

I am not the only scroll-hater out there. Arrows jumping 'full' record groups is beautiful in action in this LineItems. My customer products sales (which contain many calcs, ie, frequency percentages, purchasing patterns and ship comparisons) must be seen to be believed. But I reserve decision until all tests and studies are completed. My sample file was tested across network all last week and was lightening fast (* manual testing).

Two final questions at this point (aren't you glad) to keep me moving towards my goal? If it's already been explained, I apologize in advance for not *getting* it. But these questions will keep me moving forward in my testing of it:

1) How are Value Lists interpreted across the network? Does the guest, upon making a call for VL data (either from pop-up selection), calculation or script, only retrieve it once? Since VLs are indexed, I would think it wouldn't need to ever ask for it again (during that User session). Packets refer to data but, to FM, are Value Lists data in the same sense (requiring communication with Host)?

2) Are there methods I can use to better capture the timing of this process? * Layout switch can capture start time but I've been unable to determine proper end-of-portal-redraw time. And I dislike manual start-stop actions because of possible User error.

Thank you both for helping me with this. :

LaRetta

[Søren Dyhr]

so the elaborate 2^0, 2^1... method is no longer required.

No, and I even utilized the knowledge ...without making the connection

--sd

[Søren Dyhr]

How are Value Lists interpreted across the network? Does the guest, upon making a call for VL data (either from pop-up selection), calculation or script, only retrieve it once? Since VLs are indexed, I would think it wouldn't need to ever ask for it again (during that User session). Packets refer to data but, to FM, are Value Lists data in the same sense (requiring communication with Host)?

I've just heard Danny Mack saying in the podcast with him, that the new server-clientmodel have biased towards calcfields to evolve on the server while scripts runs on server ...but only to get obscured by the use of global fields residing on clients as well. Which is a significant change in the demands to the machine server runs at, which now should be a "Server Class"....

--sd

[comment]

I am not the only scroll-hater out there. Arrows jumping 'full' record groups is beautiful

I'd be very reluctant to generalize here. To me, scrolling is an accepted, intuitive user interface element. Of course, if it drags like molasses, then it should be eliminated. But I would think the problem is not the scroll itself, but the amount of records that CAN be scrolled. Correct me if I'm wrong (and only you can test this) but if the group size is 12, and the portal has 10 rows with a scroll bar - I believe it would be just as fast as a portal with 12 rows and no scroill bar.

I don't know the answer to question #1, just a small hint: In my demo file, if the VL needs to be changed, it takes a mighty refresh (with cache flushing) for Filemaker to notice. To me that would indicate that the VL is stored in the cache, and therefore no calls are made. But apply a large dose of salt to that. And I have no idea about question #2.

[LaRetta]

Soren, it's precisely because I had heard Danny Mack's podcast that spurred the question. Thank you for Barbara's pdf. It was very valuable in visualizing packet-passing; which I have been questioning since I started using FM a few years ago (although I always termed it as 'host and client talking to each other'. Questions such as: Should I store graphics or lookup tables (large zipcode tables etc) on client; how are globals used; how is data passed and when do these calls take place? Heck, until we networked 8 months ago, I had no idea what it felt like to get a record-lock.

Michael, as always you make perfect sense and I agree. A relationship of 12 records is not worth restricting. However, until FM provides the option of SHOW/NO SHOW SCROLL via script, decisions need to be made. And if one has a relationship which might contain 12 related records or 100 or 1,000 I would rather provide button movement with two lonely records on the second portal, than expect Users to scroll the 100. Of course, I could provide two portals and Count() related and switch to different layouts based upon the results (one with scroll and one with button/no scroll). But that inconsistency of process (from a User perspective) is not a good option. I want their views to be consistent ... not change (when viewing Contact LineItems for instance) depending upon record counts. Of course some portals are fine to always have scroll when I know they're smaller data-sets. The power of related is this very flexibility and unlimited record count. But until portals (our most User-friendly view of related) also match this flexibility, we need to step onto one side of the creek. Even filtering can't determine the resultant record count before it actually happens which is too late because User is already on the layout in which they expect to see the results displayed.

A drawback of filtered portals: User doesn't filter (isolate the full related) until they are on the layout which is then too late because the full relationship has been established (and drawn) by then. It is akin to script sequencing for report/view generation - whether to isolate your record set before layout switch when providing large aggregate results or summaries and freeze windows .. timing is everything. If providing portal filters, I think it might be better to have relationship based upon NO related at layout switch, then filter to CREATE the relationship as needed. Again, depending upon the needs and anticipated related sized. Just another of my long list of speculations.

Thank you both so much. And if either of you know any resources which point to packet-handling or host/client communications (particularly in vs. 7) I would be most grateful. Of course I've devoured Tech Info and Knowledge Base (and still am) and I'll do all my own homework. I can't seem to be fed information fast enough. I believe I've figured out how to grab screen redraw end-times for my testing. Hopefully, I'll run full tests tomorrow (when everyone in office is gone and I can have total control the network traffic, record sets, etc.). If I don't respond immediately with results, just know that this will not leave my plate and it'll mean I'm working on it. I think it is very important stuff! Of course, I think everything is.

Now see? I kept this pretty short considering the depth and importance of the subjects discussed!!

L

[comment]

portals (our most User-friendly view of related)

Are they really? I tend to lean more towards List views. Now if only there was a Sidebar layout part...

[Søren Dyhr]

Are they really? I tend to lean more towards List views. Now if only there was a Sidebar layout part...

I agree here, thats why I mentioned the new windowing feature for GTRR issued from a button!

LaRetta, there is something on the packets dug down somewhere in the whitepappers have Steven H. Blackwell assured me ...I'm still chasing...

--sd

[LaRetta]

Comment said ...

Are they really? I tend to lean more towards List views. Now if only there was a Sidebar layout part...

Soren said ...

I agree here, thats why I mentioned the new windowing feature for GTRR issued from a button!

I agree. But my Users don't.

In prior FM versions, I rarely used windowing. When 7 arrived, I thought Users would love them!! They didn't. No matter where I placed the window or what size, even with easy click-dismiss ability and GTRR-efficiency, they complained that they wanted to see everything together on one layout so it was all visible at one time. They wanted their portals back. And I gave in.

I want to use both list and portal. I just want my portals to behave and be as quick as list view when I do use them. And that means taming them by removing scrolls. Restriction will eliminate portal pop, decrease redraw speed, eliminate ugly scroll, provide list-view page jumping and ... one can even have a sidebar (I think).

ps - I just had to use the new Spoiler feature. It's very cute!

LaRetta

[Søren Dyhr]

on one layout so it was all visible at one time.

Beyond it being slightly contradictory ...making selections to be shown in a portals, is simply not everything shown at once.

I'm sure this is due to a long abuse from websites that does it like mentioned in point 9. in this:

http://www.useit.com/alertbox/9605.html

Maybe your clients are ready for a intranet web-solution instead, using these cool cool spoiler features both back and forth that is one of the best details at:

http://www.fmpug.com/

...because the user is never in doubt why a box expanded or collapsed.

--sd

[Søren Dyhr]

Comment wondered how fast multiple omitting is compared to the other methods posted in this thread.

LaRetta you're the one burdened with data, please speed check this technique, and lets forget about the clipboard tampering for a short while. Then...

The saving of it is done by first pasting it to a global text-field, and if it remains empty, is it saved to a global container-field. When the scripting is done cut the saved object back into the clipboard.

Meanwhile have I gotten rid of the cool algorithm of Edoshins, that have gone redundant.

--sd

Restricti2.zip

[LaRetta]

I was incorrect (made another generalization), Comment. I said my Users don't like multiple windows but in truth my power Users like them. It also seems that Mac Users are more comfortable with windows (now why did that sound funny?).

Windows OS is not as intuitive as Macs (from what I gather). However, in most businesses it is comprised of 70% non-power Users who only HAVE to use the computer to accomplish their regular jobs. And my foremost goal is to provide solutions for them. Power Users can adjust down but if I design for the lowest common denominator, new-staff training time is greatly decreased.

Oh! And we ARE going to web publish with FX.php (which I'm learning thanks to FMPug and Andy)!!

There is a lot of material and ideas here. I've used multiple omit with Fast Summaries but I'm ashamed to admit I'm weak on the technique! I will include this in my testing as well.

:grin:

[comment]

first pasting it to a global text-field, and if it remains empty, is it saved to a global container

I've been playing with this for some time now, and it seems a global container alone can handle any type of data in and out. Perhaps something like:

Go to Layout [ "Parent" (Parent) ]

Paste [ Parent::gClipboard ] [ Select ]

If [ Get ( LastError ) ]

Beep

End If

Go to Layout [ original layout ]

I haven't been able to generate an error yet, so I'm not sure what to put there.

[Lee Smith]

Clip Save By: Parker Bennett URL: http://www.fmfiles.com/tnt8.html