Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

record number in grid not table

Status
Not open for further replies.

ameedoo3000

IS-IT--Management
Sep 20, 2016
233
EG
hi all
how can i get the record number or row number in grid not table. recno() only get The record number is given in the table and not in the actual grid , especially after filtering.
 
Yes, you must include an empty field in the main table.
The code is then executed.
You are right, Olaf.
As for the work of the any filter at any time or any index at any time, this can be done by putting this code into a Method that is called at any time and with anything.
Greetings Dear Olaf.
 
>As for the work of the any filter at any time or any index at any time, this can be done by putting this code into a Method that is called at any time and with anything.

That only solves the problem of not needing to write this code multiple times. This is a very usual thing to do.
It doen't solve the performance problem you'll only ever see, if your or your customers data grows. It shows earlier than you think.

And you can have that field in an extra table or cursor, just think about RELATIONs. But also that won't solve the performance and refresh problem.

You get something, that works nice with perhaps even up to 10000s of records, and might think that's good enough. But things get ugly, if it begins to slow donw things, this will happen more suddenly than you think.

Bye, Olaf.
 
Olaf said:
That only solves the problem of not needing to write this code multiple times. This is a very usual thing to do.
It doen't solve the performance problem you'll only ever see, if your or your customers data grows. It shows earlier than you think.

And you can have that field in an extra table or cursor, just think about RELATIONs. But also that won't solve the performance and refresh problem.
Does this also apply to the code?
I think it will be more complicated and slow.
In any case, if I need a way to deal with more than 10,000 records, I will definitely fill you with no doubt. I'm still very young in Fox programming and I'm still learning from you. This is a great honor for me.

Bye, Ahmed.
 
>Does this also apply to the code?
What do you mean with this question?

Bye, Olaf.
 
I mean this question (is your code will cause the same problems and slow for over 10000s of records as you said about my code. or not ?)
 
putting code into a function or method to be able to call it instead of having to rewrite it everywhere only lowers the code necessary to write or copy and is a good move about maintenance, only one place needs to be changed, if ever. That's code recycling, that's one major part of both procedural and oop programming. But how on earth would it speed things up? Or slow things down (essentially)? You still execute the same code.

Bye, Olaf.
 
Yes, you are always right, dear Olaf. Things can not be overstretched. Yes.
Thank you very much, Professor Olaf.

Bye, Ahmed.
 
I'm not enforcing anything upon you, I just give advice. If you just expect encouragement, you're asking the wrong guy. I just want to spare you the pain of learning, but sometimes everyone might need to make his own experience with something to believe.

I am surely more experienced, you know that, but I'm also not perfect, noone is. That means there's neither a need to try to outsmart nor to praise me or us.

You can take your ideas and what you learned and try to get as far as it takes you, you may be satisfied and never hit barriers I hit years ago, hardware goes faster all the time, but alone from the maintenance point of view anything you need to do to accompany some very basic native behaviour you can do with a single command like SET ORDER, that needs a magnitude more lines, may not be worth it.

You can always argue code once written and proved to work is done and causes no further work anymore, it simply works and is a single call of a function or instanciation of a class as an object. But developing generations of code/libraries using previous generation code then just leads to unmaintainable heaps of code layers. So that thought does not hold true over longer time periods.

So whether I am right with my pessimistic view or you manage to reach your goals will only really turn out several years from now. If you manage to realize all features you think of within the next few days will not prove anything, this still is not where I would talk of a success. Things have to work over a longer period of time, or maintenance of your first code will keep you from advancing, learning and doing more. This can really become a burden you can't dislodge easily aka maintenance nightmare.

You make the impression to want to fly, when you even can't walk, and you're victim of something I see in many non computer savvy project managers, wanting a seeminlgy easy idea to be done, they saw elsewhere, and as this exampe shows this hasn't to be from a sci fi movie lilke a holo deck or a computer you can simply ask for something. Then on the other hand you can do things that make their jaws drop. It often is hard to explain why easy seeming things are hard and hard seeming problems are really easy to solve. You can do handwriting or even face recognition (using such a library or module) and several companies work on self driving cars, but SET DECIMALS TO 11 and ? VAL("75397.275") and you get 75397.27499999999, so computers can do stuff only humans can also do, maybe even better than humans, but they can't even convert a number in a string to the same numeric representation they can calculate with? Even though they are named computer? computing/calculation machines? Really?

Yes, that's the way it is.

Bye, Olaf.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top