Jump to content
Sign in to follow this  
glzm0

portal-question: feedback which position of the list the user clicked?

Recommended Posts

glzm0    0

I do have a portal with 8 rows.

When I click on one of them, then the "Detail-Infos for Person XYZ" appear above the Portal.

This works like a charme, but ...

The Portal jumped back to the first position in the portal list.

So if the user scrolled a lot and want to get some infos of the person, he has always scroll again all the stuff only to get to the last few persons.

And maybe he also forget in which position he was after that magical jump?

Is there a way to keep the position in the portal?

Maybee fetching the status which position or row I clicked in the portal, and then jumping to the calculated positin instead of the normal first position?

I hope you understand what I want :

Share this post


Link to post
Share on other sites
LaRetta    480

I believe I understand ... if you go to Format > Portal Setup, one of the options is to Reset Scrollbar when exiting record. Uncheck it.

If this isn't what you need, let us know! :wink2:

Share this post


Link to post
Share on other sites
glzm0    0

This box is already unchecked. ******* it doesn't work.

Thanks for your fast help anyway :

anybody any other hints?

Share this post


Link to post
Share on other sites
comment    1,390

When I click on one of them, then the "Detail-Infos for Person XYZ" appear above the Portal.

Can you describe in detail how this is done?

Share this post


Link to post
Share on other sites
glzm0    0

: OK I'll try:

I have one Table and one relationship to itself.

In my Layout you can see the informations I filled in for the person.

In this Layout there is also this portal which shows a list of all persons from the self relationship.

I made an invisible button in the portal and linked it with the funktion "go to relation record" (sorry for the bad english =) in german is "Gehe zu Bezugsdatensatz")

Then I see the whole infos for this person.

But the problem is, that the portal always jumps to the first entry in this list. The behavoiur I describe is only given for the portal. The rest works like it should : .

So what does the customer do when he scrolled the list in the portal all the way down to the records with the persons beginning with "s". When he now clics on a person the portal jumps back to first entry and the customer had to scroll all way down again to get to the letter "s".

How can I solve this, that the portal stays in position.

I don't know why this hint from LaRetta doesn't work. The Checkbox wasn't aktivated (reset scrollbar...) all the time. I can't recognice any different behavours if the box is checked or not.

In my layout the customer is only able to read. He can't change any datas. Maybee this is the problem that there are no editable fields? also no editable fields in the portal.

:(

Share this post


Link to post
Share on other sites
LaRetta    480

You will need to use script and not Specify Button. See if this produces the results you wish:

Set Variable [ $PortalRow ; Get ( PortalRowNumber ) ]

Go To Related Record [ sameRelationshipNameAsPortal ; using current layout ]

... don't check either checkboxes on 'show only related' or 'matching found set'

Go To Portal Row [ Select ; First ]

Go to Portal Row [ by calculation $PortalRow ; no dialog ]

... this will consistently leave the portal on the last row and the record last selected. Even when scrolling through records, it will remain at the bottom of the portal, viewing the same record.

BTW, this was solved (except for reverse theory) for me by Comment just yesterday.

Edited by Guest

Share this post


Link to post
Share on other sites
LaRetta    480

Of course if you edit the main record, the portal will not maintain that record's location in the portal. You would have to store that value and return to the portal via another button click.

Edited by Guest

Share this post


Link to post
Share on other sites
comment    1,390

The reason why this happens is that you are going to another record (try going to the current record to see the difference).

You could try getting back to the portal row, as LaRetta suggested, but I think having the clicked row jump down to the bottom would be equally distracting.

A better solution, I think, would be to make the button put the selected record's SerialID in a global field. Then define a new relationship matching the global field to SerialID, and place fields from the related TO on your layout.

Share this post


Link to post
Share on other sites
fabriceN    5

Have a look at this :( http://www.bh-a.com/downloads_1.1.html#VisiblePortalRows

This custom function (with layout objects) lets you know exactly what rows are visible. I use it very often to do what you describe.

Your script should look like :

store this function result in a variable

go to the record or do what you want

restore portal position.

Share this post


Link to post
Share on other sites
comment    1,390

Unfortunately, portals don't always scroll as neatly as one would like (see screenshot). I don't know of a way to "restore portal position" EXACTLY to what it was; going to a portal row would exhibit the same shifting problem.

I cannot help wondering what's the point in suggesting this solution to a beginner with a regular version of FileMaker 8.

portal.gif

Share this post


Link to post
Share on other sites
fabriceN    5

True, it's only a row per row precision. So exactly was maybe not the word, even if my post is describing relatively precisely what the function does: returning an exact list of visible rows, not positionning exactly to original position.

As to FileMaker version, I hadn't read it. Does it never happen to you ?

Now, between giving a not-so-easy answer and saying it's impossible, I still wonder what's the worst.

I could also have posted this file, but it took me hours to understand (it uses no custom function though).

My point is that 'simple' is not always 'easy'.

EDIT : in this file, the point is to know what's the last visible row.

DerniereLigne.fp7.zip

Edited by Guest

Share this post


Link to post
Share on other sites
comment    1,390

between giving a not-so-easy answer and saying it's impossible, I still wonder what's the worst.

I believe I suggested a rather simple (and easy) solution to the problem.

I could also have posted this file, but it took me hours to understand (it uses no custom function though).

For the benefit of others who would want to understand it without spending hours, I'll say this: IMHO, a demo file should not hide layout objects that are required to make the demo work.

However, even this file's technique, though interesting, does not offer a solution to the problem at hand.

Share this post


Link to post
Share on other sites
fabriceN    5

I believe I suggested a rather simple solution to the problem.

Well, if going to a record and displaying its data are made the same thing, then yes, your solution is obviously -and by far- the best.

Nevertheless, I have the strange habit, maybe I'm wrong, to try to answer the questions.

It is true though that sometimes the question is obviously looking for a too difficult solution and that there is a much simpler way. It didn't seem that obious to me in this case.

Now, Comment, the reason why I'm here is -like many other I guess- to improve my own skills, thanks to people like you and others. Occasionally, I see an opportunity to help, and didn't see till now a good reason for not doing so. But if my attempts to help are percieved this way, then just say so, and I won't bother you anymore.

Share this post


Link to post
Share on other sites
comment    1,390

An afterthought:

My point is that 'simple' is not always 'easy'.

Perhaps, but it can be lot easier when it's not over-complicated. As an example, here's essentially the same thing as the file you have posted, except a lot simpler (with the added bonus of not breaking on duplicate values).

PublishLastRowNumber.fp7.zip

Share this post


Link to post
Share on other sites
Genx    1

Guy's we're all here to help, so everyone just calm down please.

Fabrice - Don't take Michael's criticism's the wrong way, though i can see that in this case he's coming off a bit harsh. I personally learn more through criticism of my idea's than through anything else and would have to say that about 1/6 of my posts are still criticized ... or suggestions are made for much simpler solutions. This is one of the primary reasons I post so much on these forums, it's like constant peer review.

Michael, please don't dismiss people's ideas so roughly as they may take it the wrong way.

Share this post


Link to post
Share on other sites
LaRetta    480

"...please don't dismiss people's ideas so roughly as they may take it the wrong way. "

Huh? If you re-read the posts, you will see nothing inappropriate was said at all. At no point were forum rules broken or even approached. It is fine to disagree on this forum. If to simply disagree is considered 'rough' then we all might as well go home. Remember - we can even strongly disagree; that's how greater ideas are many-times born.

Share this post


Link to post
Share on other sites
comment    1,390

I have the strange habit, maybe I'm wrong, to try to answer the questions.

There's an ongoing debate here about this policy. Answering the question as asked is often not providing a solution to the real problem behind the question. I think this thread is a good example of that.

Try to put yourself in OP's shoes: what would you have learned from trying to implement your suggestion? Even more importantly: what would you have NOT learned, if your question was answered literally, without trying to understand why are you asking it?

But if my attempts to help are percieved this way, then just say so, and I won't bother you anymore.

This is an open forum, and I am only a rank member here, same as you. Any member can post what they think is helpful - including corrections, notes and even criticism of other member's posts. If I make a mistake, I expect other members to correct me. If I make a suggestion, and another member knows of a better approach, I expect them to say so and give their reasons why it's better than mine. Otherwise we will learn nothing - and I think that's why we are all here.

Share this post


Link to post
Share on other sites
Genx    1

Okay, maybe it was a mis-interpretation - "My Bad". Sorry Michael.

I didn't actually read the posts properly -- just Fabrice's reaction to Michael's ideas.

Anywho, i'm gonna go what was it you called it LaRetta... skulking... lol, yeh i'ma go do that.

Edited by Guest

Share this post


Link to post
Share on other sites
LaRetta    480

Hey, Alex, you spoke up because you care - nothing wrong with that. I've no doubt that two very bright people (Fabrice and Comment) can work through this just fine on their own. :wink2:

Edited by Guest

Share this post


Link to post
Share on other sites
Vaughan    101

Sorry to change the subject...

I tried hard to understand the CF that Fabrice referred to earlier but could not. Fabrice then posted a sample (that Michael's further clarified) that appears to do the same, with just a global variable and a calculation field. Wow.

Am I right in guessing that it works because, as the portal is scrolled, FMP internally re-calculates the global variable as the related records scroll into the portal? But to do this the calc has to be displayed in the portal itself?

The CF in the earlier example uses the GetLayoutObjectAttribute function with a paramater that I can't find documentation for (at least in the help files). It looks equally amazing... could you tell me what it is?

Thanks!

Share this post


Link to post
Share on other sites
Raybaudi    58

yes !

One parameter more than the 3 expected !

GetLayoutObjectAttribute ( objName ; "top" ; 1 [color:red]; $$cf_counter )

Share this post


Link to post
Share on other sites
fabriceN    5

Okay, here it becomes interersting again.

So, sorry Comment, I apparently misunderstood your... comments. Let's forget about this. I'm sure you know I tried to help the guy. Wether the way I did it was appropriate or not is secondary. I agree with your conclusions on the 'debate', except that this was not my understanding of THIS very question. You might be right. End of subject.

About the sample files.

'my' function (VisiblePortalRows) actually needs two named objects :( the portal, and an object within the portal row. In the particular case of the demo file, the object covers precisely the portal row, so what is returned is a list of visible rows, even if a row shows only 1 of its pixels. But if you were interested in the list of the rows showing a text field (which can be smaller than the portal row), you could pass the field-object name to the function.

About the documentation of GetLayoutObjectAttribute, there is a mistake in FileMaker's help, but if you double click on the function in a calculation window, it will appear clearly :

GetLayoutObjectAttribute ( objectName ; attributeName {; repetitionNumber ; portalRowNumber} )

About the second file now. It is not mine but Agnès Barouh's. And as I said, it took me a while to understand it (you don't know her, but she's a French 'FileMaker Artist', who would make Daniele's brain seem absolutely normal by comparision ;-).

The idea here is that FileMaker evaluates unstored calculations from top to bottom in a portal. So putting a field that declares a variable in the portal row causes a multiple evaluation of it, in 'increasing' order.

Hope this helps :

Share this post


Link to post
Share on other sites
comment    1,390

Just to add some more clarifications:

The two techniques do not do the same thing. With the variable, you always get the result of the last evaluation. So the last visible row overrides all previous results, because it's the last one to render thus the last one to evaluate - but you would be hard pressed to find out anything about what's in the first visible row, for example.

The custom function goes row by row, and compares the portal's top and bottom boundaries to the boundaries of an object in the current row. Somewhat similar to testing two date ranges for overlap. This way you can get a list of all visible rows. It would be also possible to split the list into fully visible and partially visible, or even calculate precisely the revealed fraction of each row.

Share this post


Link to post
Share on other sites
glzm0    0

Guys you are all great :

@fabriceN: : whoooo... In this point I am still a beginner. Am I right that I have to buy the LayoutProperties 2.0? At the moment about $200 are a littlebit to much for my wallet. :( And a littlebit to complicatet at the moment for me. I hope to reach your skill level someday.

@comment: I discovered one thing by myself. My portal was in sort order. But I forgot so sort the source table. Now I have sorteted both.

The behaviour is more friendly now. The portal jumps to the chossen person and put it in the last visible position of the portal. :

@LaRetta: I hope I didn't annoy you :) but your solution is the one I also discovered by myself. :) I prefere to jump to the forst visible position with the choosen person, plus I made a field which marks the person a littlebit more with color, that the user realize, that this is the person he had choosen.

thanks for the debate which is/shoul be the best solution :

This is what our mind expands ... :)

fm_example1.png

with kind regards, glzm0

Edited by Guest
added the screenshot

Share this post


Link to post
Share on other sites
comment    1,390

My portal was in sort order. But I forgot so sort the source table. Now I have sorteted both.

The behaviour is more friendly now.

I don't see why sorting would make any difference to the behavior.

If you don't mind the clicked row jumping to another position, then go ahead with LaRetta's suggestion. For myself, I would find it very annoying.

Share this post


Link to post
Share on other sites
Raybaudi    58

The idea here is that FileMaker evaluates unstored calculations from top to bottom in a portal. So putting a field that declares a variable in the portal row causes a multiple evaluation of it, in 'increasing' order.

Uhhh...what a nice idea !! :

Share this post


Link to post
Share on other sites
fabriceN    5

@fabriceN: : whoooo... In this point I am still a beginner. Am I right that I have to buy the LayoutProperties 2.0? At the moment about $200 are a littlebit to much for my wallet. :( And a littlebit to complicatet at the moment for me. I hope to reach your skill level someday.

Actually, LayoutProperties is a completely different thing, but I designed it to make my life easier, not more difficult :

Glad that you found, and even invented, the right solution for you.

Share this post


Link to post
Share on other sites
glzm0    0

if the table "addresses" is NOT sortet and the self realation "adresses 2" IS sortet, then I have the odd behaviour :

If BOTH ARE sortet, then it's more friendly and puts the choosen one to the visible end of the portal.

I don't know why :( but that's the fakt I realize. Maybe this happens cause if I press the button and call my script, the script don't take the ID of the record. The script grab the number of the record. This means: I click on record number 9 in sorted portal "addresses 2", then call record 9 in the "addresses". And this is not the same person as in sorted order :.

Please correct me if I am wrong.

I use the funktion "Hole ( Ausschnitt ZeileNr )" I don't know the right translation maybe "get number of portal row"

At the moment I am staying on the tube. How do I jump to record with an given ID or an given Record ID (indidual given by filemaker)

:)

Share this post


Link to post
Share on other sites
comment    1,390

You should give each record an auto-entered serial number ID. That will make A LOT of things much easier.

Share this post


Link to post
Share on other sites
Ugo DI LUCA    0

Hi Mike, LaRetta, Daniele, Vaughan, glzm0, Mister Nordmann and whoever I missed here :

Whatever the technique, it should resolve in any case, as an universal solution.

One problem I can see is that 'visible' with FileMaker really means visible ( in the context of the window ) as these screen captures tries to demonstrate.

Your solution, Michael, as the one suggested by Agnès on the french Forum, is too dependant on screen refreshing issues, in my opinion. True there's little chance someone ever reduce a window where a portal stays, but we never know...

Then your list would just grab those rows in the windows rather than those in the portal itself

Image_1.png

Image_2.png

Edited by Guest

Share this post


Link to post
Share on other sites
comment    1,390

Hey Ugo, nice to see you around again!

Your point is well taken. The truth is I only did it as a challenge. I still can't see where this information, whether derived from a variable or from a CF, could be useful. But in fairness, if someone did find a problem for this solution, it would most likely be in a script, so they could make sure the window was zoomed to fit before evaluating.

Share this post


Link to post
Share on other sites
Ugo DI LUCA    0

Well, at first when the challenge was posted, I did say 'who cares' and even didn't tried myself convinced there was really no use for that.

But then cames the time when in a portal showing a foundset, I wanted to omit one record from the shown list. The record being selected now should be the previous one. Keeping the current portal row in a variable, it was fairly easy to get back to that row later, but the go to portal row command brings the focus to the last visible row.

What I wanted is that the cursor and focus would stay in the same position, in case he wanted to omit more tahn n record in a row.

Then, knowing the exact position of the first and/or last in the portal is the solution to determine which row to target ( last ) in order to maintain focus.

Does it seems as an example you may use once ?

Anyway, nice to be back here, as always. :

Share this post


Link to post
Share on other sites
comment    1,390

I am not a big fan of found set portals (or self-join portals in general), so it's probably not for me - but I see your point.

I hope we'll see more of you - it's not the same without you and JT.

Share this post


Link to post
Share on other sites

Because this custom function's example solution uses a return-delimited list of numbers, it is not that easy to apply to other kinds of portals. Even so, I think it might help me.

The larger issue is that I believe there is a bug in FileMaker's portal behavior. Others have reported situations in which "Reset scroll bar when exiting record" is unchecked (not checked), yet the scroll bar resets anyway.

In my case, I have a portal showing a list of related images. Whenever the user clicks on a row in the portal, the scroll bar resets -- even though that Reset box is unchecked.

I can understand this behavior if the user clicks OUTSIDE the portal to navigate to another record. But not when the user clicks INSIDE the portal. When I click on a portal row, that row should not disappear from the portal view.

Edited by Guest
spelling

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.