Dynamic Lookup fields

[Ugo DI LUCA]

Hi,

FM7 ntroduced the LookUp and Lookupext functions.

It would be awesome if the Source field could be hardcoded in the future releases.

Currently, I can't see any reason why this couldn't be made possible, and it will open wide the door for new perspectives in the Relationship flaws.

LookupNext(Case(x=y, Company::CompanyTable;Company2::CompanyTable);Higher)

So you could dynamically swich from one reference to another, even based on some related fields.

No ?

Don't tell me it is possible, I didn't tried, but as the Source is SourceField rather than FieldName, I deducted it wasn't.

If it is, then you can bet how happy a man I could be, even if stupid.

[djgogi]

Actually you should try it

Dj

[Ugo DI LUCA]

Doh !

This is just fantastic.

I already imagine the kind of dynamism such an option offers.

Thanks Goran.

[Ender]

Can you say more about how fantastic this is? So far the usefullness of these new lookup functions has eluded me.

[Ugo DI LUCA]

Well,

The Lookup ( ) is just a calculated lookup, which is why I was kind of curious why it existed if it couldn't have worked in the hardcoded way.

If this can be done, then, using this function, provided you stored the "link" in any place (say another table or a global field), you can dynamically decide from which table this lookup should occur, and from which target you want the value to come from, by enclosing the link or involving a GetField("gMyLink"), where glink can be even stroed in a distant table actually.

Which means you can perform a Lookup by using a parameter stored in a distant file, and targetting dynamically the field you wish, and even the value (lower or higher).

Well, that's just amazingly powerful in my belief.

The LookupNext has also a lot of neat tricks burried with it. Make a search for LookupNext in the late month, as Bruce Robertson provided a cool way of getting the last number of a relationship using this function and the auto-entered global.

There are plenty of favours with the v7 for sure, but the small examples I've exposed are just the smallest I could think of.

It's kind of the same revolution as the GetField( ) was.

Implementing Lookup with a Let ( ) I'm sure will provide new ways of transfering and propagating data.

Hope all this make sense.

[Ugo DI LUCA]

I have to try this tonight to see if it works, but here is something possible, as far as I understand.

Let ( [

T = gTable;

S = gSource;

M = gMessage;

R = GetField("T &"::"& S")];

LookUp(R;M))

Provided the Table relates together, you may dynamically set FM to the desired path for the desired field.

Wouldn't this be powerful ?

And let's dream a little more (I still didn't tested eitherof the solutions above...)

Let ( [

T = MyRelation::gTable;

S = MyRelation::gSource;

M = gMessage;

R = GetField("T &"::"& S")];

LookUp(R;M))

which means you can decide which field to lookup based on distant parameters may be even stored in this same table.

I dunno what this could bring up, but it sounds as if I have enough to work with for the next 10 years.

[bruceR]

Now just one more thing. Let all of this be part of the interface file. So the target field is just a "dumb" data field (not lookup, not calc) and your interface file controls where the data goes as you describe above. But I don't think we can do that yet.

[smorr]

Ok -- I've looked at this and thought about this and looked at it again... and I am sure something is escaping me here...

How is this different from just using a calculation using a relationship?

Let ( [

T = MyRelation::gTable;

S = MyRelation::gSource;

M = gMessage;

R = GetField("T &"::"& S")];

if(GetField®<>""; GetField®; M)

)