use different SourceTable for different pages of tab control

jks

How can i provide different source table for different pages of the tab control?

e.g Customer Card uses Tab control having 7 pages. I added one more page to that tab control. I want to use different SourceTable for newly added tab page.

I wrote C/AL code, retrieved values from the table(which is not a customer table) and assigned those values to the fields available on newly added tab page. But it makes those fields disabled eventhough Enabled and Editable properties are yes.

Please help.

janpieter

For every tabpage create a new form with different tables.

Put subforms on every tab page and use the SubFormID property to assign one of the newly created forms. When running the main form your created form will appear within the subform control borders.

Be aware that placing 7 subforms on 1 form may cause performance problems.

jks

No,no. I don't want 7 subforms.

One form is there and it alreadly contains 7 tab pages. All those 7 tab pages are using same Source Table. I added one more tab page and only for that tab page i want to use different SourceTable.

Can i do so by setting the SourceExpr property of the textfield which i placed on newly added tab page?

janpieter

You can bind a control to a variable by setting the SourceExpr property to the variable you want to show.

For example:
SourceExpr = SalesLineRec."No."

But the field will not be editable. Therefore it is not really recomandable. The only good way to alter table data is by using forms (and subforms) that are bound to that table and not variables so i still sugest to do that.[/code]

jks

Ok.

Thanks.

kine

One form = One source table... Not more... if you want more, you must use subform... no way around...

eromein

SalesLineRec ?

Why not call it SalesLine, just like standaard Navision does?

Before you know it people will post fix everthing... I've even seen:

SaleLineRecGlb or SalesLineRecPar! Never seen this in standard Navision though. So why start doing it????

But still, it's better the pre fixing. Imagine these kinds of variables:

GlbRecSalesLine or even better LclDecQty.

I know Qty is a variable, IT SHOULD ALWAYS BE DEFINE LOCALLY and don't tell me you need to know that QTY is of the type decimal. I MUST BE A DECIMAL! If this is a Integer a new training is needed!

Conclusion: Qty is the only right way yo define this variable. You don't even have to have good arguments for this, the best reason is STANDARD NAVISION!

Maybe this should be a new topic on the forum...

janpieter

somehow off topic but i totally disagree.

Dont tell me navision standards are highly readable.

Now people can see it is a record whilst otherwise it could just as well be an automation variable for example. I know there would not be any confusion in this topic but just as well.

Oh well and it is not really our conventions but i see a lot of people juse it like this and thats why i posted it here like that.

(There is nothing wrong with having an own convention as long as it is done companywide.)

oh in fact we use:
lrecSalesLine (local record sales line)
grecSalesLine (globar record sales line)
liCount (local integer)

so 1 letter for the variable being local or global and 1 letter for simple variable types or 3 letters for complex variable types.

So more in the direction of C++ style conventions.