I would like to put a label like this in a custom controller:
record %%recordIndex%% of %%maxRecordIndex%%
Unfortunately, this code does not work with forms from different data providers (it just uses the first data provider listed in the repository on each form).
%%currentcontroller.recordIndex%% is not the answer…
Hi David,
Unfortunately this is not possible yet.
I’ve added it to requested features.
Gentlemen,
I notice that this dialog took place back in May. Has the ability to track:
(1) Current Record
(2) CurrentRecordNumber
(3) CurrentRecordCount
been added to the newer versions. If so, how would I recreate the FMPro calculation:
" Current Record : " & Status(CurrentRecordNumber) & " Found Count : " & Status(CurrentFoundCount) & " Total Records : " & Status(CurrentRecordCount)
All the best,
Dino
You can do most of what you want to do easily. Create a label and check on the property “DisplaysTags.” Then in the text property, type in %%recordIndex%% of %%maxRecordIndex%%. What I was getting at back in May is that this label only works for the form that it is placed on and cannot be placed on a custom controller and used for many forms.
Note that the numbers returned represent the state of the current found set. There is no tag yet that returns the number of records in a table – apparently this is an “expensive” operation to do on an SQL table and is being kept out for the safety of all of us ex-FileMaker developers.
I am not sure what good a custom controller is if it doesn’t show the current record number of max record numbers (total in the table or total in the found set). I hope this is no longer true in 2.1? Hoping fervently that someone will tell me so… I’ve built a custom solution for a client used to FileMaker, and there’s no way they’re going to accept it with a less functional controller. Help?!
ellen meserow
there is still a 200 block size in 2.1 and this will not vanish because there could be XXXXXXX numbers of records in the foundset. And a count can be very expensive. Maybe in a next version we could bump the block size to 400.
All,
I have discussed this issue offline with a number of developers used to working in FileMaker over the past couple of days. Here’s some thoughts (from my own personal perspective):
Servoy is NOT FileMaker! Do not try to make it behave like FileMaker. Instead, optimize your user experience to take advantage of all the stuff that you simply could not (and can not) do in FileMaker: tabpanels, show/hide, enable/disable, stylesheets, etc.
People always tell me they want to see the total number of records (in the foundset or otherwise). Why? “Because they’re used to it.” FileMaker controls the database as well as the user interface - so for them to display the total number of records in a table is trival. In SQL - this is simply not the case. Remember that Servoy is the data presentation layer ONLY. So, to “see” the total number of records - you have to query the database each and every time to refresh that total. This can be exremely SLOW in SQL (when you get into hundreds of thousands or millions of rows).
Foundset counts are similar - we don’t go and grab all the data for the foundset (when it exceeds 200 matching rows). We only get the first 200 primary keys of the matching data. WHY would you want to know that there is more than 200 records? Let me put it this way - when you search on Google and there are 20+ pages of results - do you (or do you even KNOW OF anyone) that goes past page 8? Probably not. NO ONE is going to sit there and page record by record more than 50 records.
What’s the answer? I’ve found that people really just want to FIND the data they’re looking for FAST. They want to be able to then “drill down” on that information, etc. Here’s what I personally to:
a) Forget “list views” as a form type in Servoy. I use them in tabpanels all the time - but I NEVER use them like I did in FileMaker (I never navigate right to them). I only used to do that in FileMaker to give the user a more “dense” listing of records (so they can see more than one at a time) - and then 98% of the time - they had to click to see the details. In Servoy I show a tabless tabpanel with a list view and a filtering mechanism in the header. Then I can place that anywhere on any form I want to. I can re-use that over and over and the user never has to lose context with another view or another window popping up. I’ve foud this approach much easier, much more maintainable - and when the customers use it for 1 hour - they ALWAYS say “I don’t know how we ever got along without it.”
b) By doing “a” above - I can offer the user the ability to “save” their filters - and give them names and re-apply them.
Just a couple of thoughts - I hope this helps!
Cheers,
Bob Cusick
jcompagner
Maybe in a next version we could bump the block size to 400.
Hi Johann, would you please consider to make this a selectable parameter for the solution or the server?
We already have some layouts where 200 takes lots of time because triggering lots of queries. In fact I can see solutions where 200 is far too much and other where 1000 will be acceptable.
if you change the block size without developper having the ability to modify it, i’m sure some of us will get into performance trouble.
olivier melet:
Hi Johann, would you please consider to make this a selectable parameter for the solution or the server?
We already have some layouts where 200 takes lots of time because triggering lots of queries. In fact I can see solutions where 200 is far too much and other where 1000 will be acceptable.
if you change the block size without developper having the ability to modify it, i’m sure some of us will get into performance trouble.
Now there is a rocking good idea. It would also help in reducing lag time in situations where the data server is remote from the Servoy server.
David
david:
olivier melet:
Hi Johann, would you please consider to make this a selectable parameter for the solution or the server?
We already have some layouts where 200 takes lots of time because triggering lots of queries. In fact I can see solutions where 200 is far too much and other where 1000 will be acceptable.
if you change the block size without developper having the ability to modify it, i’m sure some of us will get into performance trouble.Now there is a rocking good idea. It would also help in reducing lag time in situations where the data server is remote from the Servoy server.
David
I vote for this one too!
200 or 400 doesn’t have any effect when you have less rows!
You never have lots of queries if you have 400 instead of 200.
Make in configureable on one kind of level is maybe a possibility.
jcompagner:
200 or 400 doesn’t have any effect when you have less rows!
You never have lots of queries if you have 400 instead of 200.
Unless you have to show complex related data in a list!
jcompagner:
Make in configureable on one kind of level is maybe a possibility.
Sounds great, thank You.
related data is only queried when needed.
So making it the block size lower then 200 doesn’t result in less queries only more.