Source language: Translate to:

Using Variables to Make a Table Field Name

Questions about our Advanced Database plug-in

Moderator: Neosoft Support

Using Variables to Make a Table Field Name

Postby Enigman » Thu Jan 23, 2014 11:51 pm

I am creating an app to manage product sales data. I want to have separate tables for each sales year. I want to use one form for entering data for all sales years (one year at a time), so I want to do something like this:

Code: Select all
...Define the common prefix
SetVar "[SalesTablePrefix]" "Sales_"
...Specify the table for this year
SetVar "[SalesYear]" "![Year]"

With those two variables, and a database tag of "db", I would then refer to the data fields, such as the description, like this:

[db.[SalesTablePrefix][SalesYear].Description]

The above works correctly with every NB object >>>EXCEPT<<< the text input box. DBPro commands that need a table name work fine with "[SalesTablePrefix][SalesYear]" as the table name and I can output data using text label objects and the above field reference. HOWEVER, if I have ANY permutation of variable in the text box object other than the literal string:

[db.Sales_2014.Description]

... then the text box does not make a connection to the table and the field remains blank at run time.

AAAACCCCCCKKKKKKKK!!!! This is a HUGE problem.

I even tried doing this:
Code: Select all
...Define the common prefix
SetVar "[SalesTablePrefix]" "Sales_"
SetVar "[SalesYear]" "![Year]"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"
SetVar "[SalesTableDesc]" "db.[SalesTablePrefix][SalesYear].Description"


Then in the text box definition I tried:

[db.[SalesTable].Description]

or...

[[SalesTableDesc]]

NO dice.

Does anyone know why text objects work this way? Why must the field spec be a full literal string inside [ ], in other words, why must it be literally [db.Sales_2014.Description]. I have nine years worth of sales data and I don't want it all in one massive table. Neither do I want to have nine plus entry form pages all using literal strings for fields.

Any help here would be appreciated.

Thanks.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby mishem » Fri Jan 24, 2014 1:26 am

Create a virtual table using dbpCreateView.
And then variables in all of the virtual table will be displayed as necessary.
mishem
 
Posts: 575
Joined: Mon Oct 08, 2012 1:51 pm

Re: Using Variables to Make a Table Field Name

Postby Gaev » Fri Jan 24, 2014 6:45 am

Enigman:

This because when you specify a simple variable (like [currentSalesDescription]), NeoBook will refresh the display when its value changes.

But when you specify a complex value (like [db.[SalesTablePrefix][SalesYear].Description]), it does not (can not ?) check the changes in the individual (nested) variables.

A long time ago, I used a similar technique (i.e. using variables for the database, table and field names) ... but ran into other problems (like the plugin not recognizing a change in record etc.).
I even tried doing this:

...Define the common prefix
SetVar "[SalesTablePrefix]" "Sales_"
SetVar "[SalesYear]" "![Year]"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"
SetVar "[SalesTableDesc]" "db.[SalesTablePrefix][SalesYear].Description"

Assuming that ...

1) [SalesTableDesc] is the value you specified for the content of the Simple Text box.

2) the missing ] after .Description is just a typo on the forum post and not in your pub code.

3) At the time that you set the value of [SalesTableDesc], the particular Table has been opened i.e. the Description field in the current record of this Table is available to be extracted.

... it should work ... insert an AlertBox command to see the values for the variables [SalesYear], [SalesTable] and [SalesTableDesc] at the end of your code above.
User avatar
Gaev
 
Posts: 3737
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 9:00 am

Mishem,

Create a virtual table using dbpCreateView.
And then variables in all of the virtual table will be displayed as necessary.

Okay, I can investigate that.

Gaev,

Assuming that ...

1) [SalesTableDesc] is the value you specified for the content of the Simple Text box.

2) the missing ] after .Description is just a typo on the forum post and not in your pub code.

Actually, no, not a typo. You'll notice that there is no leading bracket either. The purpose of [SalesTableDesc] was to create a literal string of "db.Sales_2014.Description" and then use that to define the text box variable name. That's why in the variable I specified it with nested brackets, like "[[SalesTableDesc]]". The outer set of brackets should have said to the text box:

Make the variable name the contents of "[SalesTableDesc]". (Which is "db.Sales_2014.Description")

But that was just a test to try and debug the problem. What I want is to specify the text box variable directly as "[db.[SalesPrefix][SalesYear].Description]" just like I do for every other object and have it work for text boxes.

But when you specify a complex value (like [db.[SalesTablePrefix][SalesYear].Description]), it does not (can not ?) check the changes in the individual (nested) variables.


But that DOES work everywhere other than the text box.

3) At the time that you set the value of [SalesTableDesc], the particular Table has been opened i.e. the Description field in the current record of this Table is available to be extracted.

... it should work ... insert an AlertBox command to see the values for the variables [SalesYear], [SalesTable] and [SalesTableDesc] at the end of your code above.


The variables are created before the table is opened because I use the variables to open and manipulate the table. That's the whole point. I want to use the variables to open and close various sales years at will and use the same form to display and edit the data. It works fine for all labels and table commands. It just doesn't work in text boxes. Apparently there is something specific about text boxes pointing to table records that disallows nested variables to make the final variable name. I can do this with any object except the text box.

I'm going to try the virtual table approach and see what happens. I'll report back with results.

Thanks all.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 9:53 am

Mishem,

mishem wrote:Create a virtual table using dbpCreateView.
And then variables in all of the virtual table will be displayed as necessary.

Okay, a quick test shows that I can create a real table name using a variable assignment like:

Code: Select all
SetVar "[SalesTablePrefix]" "Sales_"
SetVar "[SalesYear]" "![Year]"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"

dbpCreateView "db" "[SalesTable]" "Sales"
dbpOpenTable "db" "Sales" "salOnTableChange"

... and then I can define all form objects with direct assignments in the syntax "[db.Sales.field-name] ... and that works in my test.

It should follow then that I can open and close table views at will using different year assignments and the form with the above object assignments will still work. In other words, I should be able to switch between years using one form.

It would also appear that it is necessary to do a Close and Drop Table on the view before exiting the app or changing sales years. Before that I ran my test twice and the second time it gave an error saying that the sales view already exists. I guess that means that the view or reference is physically created in the database and preserved over app restarts. That could be handy, but in this case I added a close and drop table for the virtual view and I no longer got the "view exists" error.

It will take me a while to convert the entire form and all subroutines, since it's freakin HUGE, but the test with a couple of fields hinted at good results. I'll report back if anything changes.

Thanks.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby mishem » Fri Jan 24, 2014 10:15 am

We solved this problem. And the only solution I have found only a virtual table.
In another way.

There are some disadvantages to the top.
But after a lot of privileges see.

Horrible translation.
But I think I understand.
mishem
 
Posts: 575
Joined: Mon Oct 08, 2012 1:51 pm

Re: Using Variables to Make a Table Field Name

Postby Gaev » Fri Jan 24, 2014 10:22 am

Enigman:
Actually, no, not a typo. You'll notice that there is no leading bracket either.
Sorry, I missed the leading [.
The purpose of [SalesTableDesc] was to create a literal string of "db.Sales_2014.Description" and then use that to define the text box variable name. That's why in the variable I specified it with nested brackets, like "[[SalesTableDesc]]". The outer set of brackets should have said to the text box:

Make the variable name the contents of "[SalesTableDesc]". (Which is "db.Sales_2014.Description")
It does not work that way ... with the double brackets ...

a) when you do ...

SetVar "[SalesTableDesc]" "db.[SalesTablePrefix][SalesYear].Description"

... you (first) get the variable [[SalesTableDesc]] to be defined as ...

[db.[SalesTablePrefix][SalesYear].Description]

... (then) to ...

[db.Sales_2014.Description]

... and since the Table Sales_2014 is NOT open at the time, it translates to null/nothing ... it does not go back later and update this value.

... just like I do for every other object and have it work for text boxes.
You can describe "the every other box scenario" later ... but I am sure that it is not EXACTLY as with the scenario you have described here i.e. a double bracketed variable associated with a content of a box/widget.

What I want is to specify the text box variable directly as "[db.[SalesPrefix][SalesYear].Description]"

Try ...

1) Define [SalesTableDesc] as the value for the content of the Simple Text box.

2) Just after your ...
Code: Select all
dbpOpenTable "db" "[SalesTablePrefix][SalesYear]" "subroutine"
... do a ...
Code: Select all
SetVar "[SalesTableDesc]" "db.[SalesTablePrefix][SalesYear].Description"

If the description needs to be refreshed with every record change in the Table, place the above command in the "subroutine" you define for the dbpOpenTable command.
User avatar
Gaev
 
Posts: 3737
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Re: Using Variables to Make a Table Field Name

Postby mishem » Fri Jan 24, 2014 10:53 am

If interested. Here we discuss this topic since 2009.

Only in 2013 a solution was found. :)

Today it is the only way to display the contents of the variables in the text box.
mishem
 
Posts: 575
Joined: Mon Oct 08, 2012 1:51 pm

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 12:17 pm

a) when you do ...

SetVar "[SalesTableDesc]" "db.[SalesTablePrefix][SalesYear].Description"

... you (first) get the variable [[SalesTableDesc]] to be defined as ...

[db.[SalesTablePrefix][SalesYear].Description]

... (then) to ...

[db.Sales_2014.Description]

... and since the Table Sales_2014 is NOT open at the time, it translates to null/nothing ... it does not go back later and update this value.

I appreciate all the help so much, but I think we are missing the point of what I wanted to do.

If I do the following BEFORE opening the table:

Code: Select all
SetVar "[SalesTablePrefix]" "Sales_"
SetVar "[SalesYear]" "![Year]"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"
SetVar "[SalesField]" "db.[SalesTable].Description"
AlertBox "" "[SalesField]"

... then the alert box displays "db.Sales_2014.Description", which means the all the literal string assignments worked. I am ONLY trying to make a literal string assignment, and that's what it did. The values of the above assignments have NOTHING to do with actual table content. They are simply defining NAMES, not retrieving content.

I can also THEN use [SalesTable] as a NAME assignment to open the correct table AFTER having made all the string assignments above. My intent was to build dynamic names for tables to open, close and work with, and that all works fine so long as I only try to edit the table using a grid element. The grid works fine with virtual assignments as do ALL other object types, subroutines, display objects, commands or what have you. The only thing that doesn't work are text boxes.

I think the difference is that all of the objects that work CORRECTLY with the above assignments are doing a simple translation of nested variables into a final literal text string, and that's why text labels and commands work fine using [SalesTable] as a table reference. I think that text boxes, the lone object that DOESN'T work, are NOT parsing out nested variables in the same way as the ones that DO work. It's possible that the text boxes are trying to resolve the variable into a MEMORY LOCATION instead of a LITERAL STRING.

Normally you can assign an array name to a text box, which IS a nested variable, such as "[array[item]]" and it will work just fine. Based on that, and the fact that the nested assignment works everywhere else, I assumed that a nested table field name variable would also work, such as [db.[SalesTable].Description] resolving to "db.Sales_2014.Description". But it doesn't. NeoBook is EITHER sensing the difference between an array memory location and a database table field name and allowing one and not the other, which would be by design for whatever reason, ... OR this is a previously unknown bug.

You can describe "the every other box scenario" later ... but I am sure that it is not EXACTLY as with the scenario you have described here i.e. a double bracketed variable associated with a content of a box/widget.

Forget double bracketing. That was just tried once when I was thrashing around trying any possible syntax that might work. The bottom line is that my intended use of dynamic table variables DOES work as intend for EVERY situation EXCEPT using a text box to edit table fields. That tells me that my syntax is generally valid, but text boxes treat the dynamic names differently. If I had only attempted to make the app using grid elements for editing, I never would have seen a problem. That again says that my idea was working, but just not for text boxes. I don't know how else to say it.

No matter at this point. Using table views appears to do what I want and it has the benefit that I don't have to place [SalesTable] in hundreds of locations in the screen form and subroutines.

Thanks again. I love how responsive everyone is on the NB forums. That really helps out during app developments.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby Gaev » Fri Jan 24, 2014 1:36 pm

Enigman:
Normally you can assign an array name to a text box, which IS a nested variable, such as "[array[item]]" and it will work just fine.

Taking your example ...

1) let us say that you have ...

SetVar "[someVariable]" "[array[item]]"

... and if [item] had a value of 7 and [array7] had a value of "abcd" ... then [someVariable] would have a value of "abcd"

2) If 2 seconds later, the value of [item] or [array7] was changed e.g. ...

SetVar "[item]" "9"
SetVar "[array7]" "xyz"

... you would NOT expect the value of [someVariable] to be automatically changed.

This is the point that you don't seem to accept i.e. that subsequent changes in the value of nested variables do NOT automatically change the value of other variables whose values were previously derived from the nested variables ... you HAVE to invoke another ...

SetVar "[someVariable]" "[array[item]]"

... so, in your example, if you need the value of a field (Description) of a record in a Table, you HAVE to issue a similar SetVar ... AFTER you open the Table and/or navigate to another record.


If you can not grasp this concept of the value of variables at different times, I am afraid there is nothing I can say that is going to help you.
User avatar
Gaev
 
Posts: 3737
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Re: Using Variables to Make a Table Field Name

Postby mishem » Fri Jan 24, 2014 2:26 pm

Variable in a text box should not be [db.[SalesTable].Description]

Variable must be [db.Virtual.Description]

You need to work with the variables of the virtual table.

And she at one time will transfer the desired values ​​of the main.

Gaev
The problem occurs only with a text field.

In all other cases, the variables are displayed correctly.
mishem
 
Posts: 575
Joined: Mon Oct 08, 2012 1:51 pm

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 3:08 pm

Gaev,

1) let us say that you have ...

SetVar "[someVariable]" "[array[item]]"

... and if [item] had a value of 7 and [array7] had a value of "abcd" ... then [someVariable] would have a value of "abcd"

2) If 2 seconds later, the value of [item] or [array7] was changed e.g. ...

SetVar "[item]" "9"
SetVar "[array7]" "xyz"

... you would NOT expect the value of [someVariable] to be automatically changed.

This is the point that you don't seem to accept i.e. that subsequent changes in the value of nested variables do NOT automatically change the value of other variables whose values were previously derived from the nested variables ... you HAVE to invoke another ...

SetVar "[someVariable]" "[array[item]]"

Ooookay, granted. I am not arguing that fact. Of COURSE if you make an assignment like SetVar "[this]" "[value]" where [value] = 4, then change [value] to 5, of COURSE the value of [this] is still going to be 4. That's the nature of a SetVar command.

My point is, ITS NOT A FACTOR IN MY SITUATION. I define variables with literal strings that are table names, BEFORE the table is opened, THEN use those string variables to OPEN the table. The table is then used normally in a form where the objects interacting with the table use the table name string to specify the table to read, write, etc.

SERIOUSLY ... AT NO TIME DO I NEED TO PUT A VALUE IN THE TABLE NAME VARIABLE THAT COMES FROM THE TABLE ITSELF.

I don't know where that assumption came from, but when I said "dynamically change table names", I meant by programmatically changing the variables with new SetVar commands. Which is the same as what I am being hit over the head with above about the SetVar command. Yes?

For example, I can specify and open a table like this:

Code: Select all
SetVar "[SalesTablePrefix]" "Sales_"
SetVar "[SalesYear]" "![Year]"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"
dbpOpenTable "db" "[SalesTable]" ""


That opens the table called "Sales_2014", (a literal variable that I built previously.)

I then work with the table using objects and commands whose table specification is [SalesTable], and I can have objects and commands that use field syntax like [db.[SalesTable].fieldname] This all works FINE.

Now I can decide to change to an older sales table, so I do this:

Code: Select all
dbpCloseTable "db" "[SalesTable]"
SetVar "[SalesYear]" "!2013"
SetVar "[SalesTable]" "![SalesTablePrefix][SalesYear]"
dbpOpenTable "db" "[SalesTable]" ""


That opens the table called "Sales_2013", (a literal variable that I built just now).

AGAIN, I then work with the table using objects and commands whose table specification is [SalesTable], and I can have objects and commands that use field syntax like [db.[SalesTable].fieldname] AGAIN, This all works FINE.

I can do this ad infinitum, close the app, and go have dinner and everything is honky dory.

That is, ... UNLESS I want to use a text box to edit fields on the Sale form. In order to do that I have to setup the text box like this:

Image

Notice the syntax "[db.[SalesTable].Description]". If I were to use "[db.Sales_2013.description]" it works fine. But when I use a nested variable like "[db.[SalesTable].Description]", then the display in the text box is empty. THAT is why I said earlier that I think that text boxes parse the variable spec different than every other object. Why? Because every other object WORKS when I use "[db.[SalesTable].Description]" or "[SalesTable]".

I am telling the text box that I want it to define the box as using the fully resolved string that goes from "[db.[SalesTable].Description]" to "[db.Sales_2013.Description]". EVERY OTHER OBJECT DOES THAT. But NOT text boxes.

My original question amounted to "Why not text boxes and is there a workaround?" Nothing more.

SO AGAIN, there is NO situation when I want the value of [SalesTable] or [SalesYear] or [SalesPrefix] to change as a result of table content. Those variables will only change when I EXPRESSLY change them with SetVar commands. And it ISN'T a matter of the text box not being able to CHANGE the definition from "[db.Sales_2013.Description]" to "[db.Sales_2014.Description]" when I change the value of [SalesTable]. I know that because the text box NEVER displays data even when I look at only one table and don't try to change it. That tells me that the text box CANNOT resolve "[db.[SalesTable].Description]" to "[db.Sales_2013.Description]" at all ... EVER. I open the app, open the sale form, and all the text boxes are blank. HOWEVER ... ALL other objects like the grid and text labels that use the table and field syntax I described ARE showing data.

One more point about text boxes. The variable spec for the source of data for the text box is NOT like a SetVar command. If I define the text box variable as "[this]", then the text box will always show the current value of [this], unlike using a SetVar command to define [this]. SetVar commands are one-shot assigments. A text box that is assigned a VARIABLE NAME of "[this]" will always show whatever the value of [this] is at the moment. OTHERWISE, text boxes would be pretty useless.

Okay, now ...I don't know where the idea came from that anything I am trying to do must be derived from inside a table that has to be opened first. I have shown that not to be the case as best I can. I do appreciate anyones help on any questions, BUT if after you read the above you are still on that point like a chew toy, then I am afriad we are going to have to agree that there is no meeting of the minds between what I am trying to describe and what you are trying to answer. If so, lets agree to discontinue the conversation.

I WILL be fixing the problem by using table views instead of nested table and field variables.

Thanks again.
Last edited by Enigman on Fri Jan 24, 2014 3:14 pm, edited 1 time in total.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 3:10 pm

Mishem,

mishem wrote:Variable in a text box should not be [db.[SalesTable].Description]

Variable must be [db.Virtual.Description]

You need to work with the variables of the virtual table.

And she at one time will transfer the desired values ​​of the main.

Gaev
The problem occurs only with a text field.

In all other cases, the variables are displayed correctly.

THANK YOU for concurring with my point.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Re: Using Variables to Make a Table Field Name

Postby Gaev » Fri Jan 24, 2014 4:32 pm

Enigman:

I wish you had used the proper NeoBook terms in your first post ... from the screen image of your last post, it looks like you are refering to a Text Entry Field tool (object) ... from your references and descriptions in the first post, I was thinking that you were refering to the Simple Text tool (often refered on the forum as a Text tool or Label).

You are looking at automatic calculation of a variable associated with an input field ... I was refering to a variable associated with an output of a tool (object).

So what you are asking NeoBook to do is to automatically "populate the Text Entry tool (box) with the value of the Description field as you navigate through the different records of the different Tables" ... all by specifying the Variable (to store Text Entry contents) as [db.[SalesTable].Description].

Notice the syntax "[db.[SalesTable].Description]". If I were to use "[db.Sales_2013.description]" it works fine. But when I use a nested variable like "[db.[SalesTable].Description]", then the display in the text box is empty.
And I would not expect it to be any different.

1) When you use a simple specification like [db.Sales_2013.description], there is a direct relationship with the database field ... if the value of one changes, so does the other one.

2) But once you specify this variable as [db.[SalesTable].Description], the change is recognized as soon as you do your first SetVar i.e. BEFORE you open the Table referenced in [SalesTable] ... which means that the value of [db.[SalesTable].Description] is null/empty ... so it shows empty.

The problem now arises that as you open the table and navigate the records, [SalesTable] does not change, hence there is no "trigger" to sync it in your Text Entry tool/object.

Because every other object WORKS when I use "[db.[SalesTable].Description]"
Years ago, when I ran into this problem, it was with the Simple Text tool/object ... i.e. specifying something like "[thisDB].[thisTable].[thisField]" as the value to be displayed in the object's space.

Are you saying that you get expected results with this tool/object ?

@Mishem/Enigman:
The problem occurs only with a text field.

In all other cases, the variables are displayed correctly.
I believe that "under the same circumstances" this will happen in other tools/objects ... Can you provide a detailed example of where such a problem does NOT occur ?
User avatar
Gaev
 
Posts: 3737
Joined: Fri Apr 01, 2005 7:48 am
Location: Toronto, Canada

Re: Using Variables to Make a Table Field Name

Postby Enigman » Fri Jan 24, 2014 6:47 pm

Gaev,

LOL ... okay ...

I wish you had used the proper NeoBook terms in your first post ... from the screen image of your last post, it looks like you are refering to a Text Entry Field tool (object) ... from your references and descriptions in the first post, I was thinking that you were refering to the Simple Text tool (often refered on the forum as a Text tool or Label).

I thought I was pretty clear. I originally referred to "Text Box" and "Text Label" objects. The difference should be obvious.

So what you are asking NeoBook to do is to automatically "populate the Text Entry tool (box) with the value of the Description field as you navigate through the different records of the different Tables" ... all by specifying the Variable (to store Text Entry contents) as [db.[SalesTable].Description].

Yes, exactly.

But once you specify this variable as [db.[SalesTable].Description], the change is recognized as soon as you do your first SetVar i.e. BEFORE you open the Table referenced in [SalesTable] ... which means that the value of [db.[SalesTable].Description] is null/empty ... so it shows empty.

No no ... NOOOOO. This assumption is where I think you are going off the rails. [SalesTable] is NEVER null, and the text input box doesn't exist until I fully start the program and navigate to the Sales form well after the table is open. I create [SalesTable] first thing in the startup actions for the app and it never changes or goes null unless I specifically change it with a SetVar command. I can use an alertbox at any time to display the literal value of [SalesTable] and it will always say either "Sales_2014" or "Sales_2013" or whatever I set it to. So at any given time, a text box defined as being connected to [db.[SalesTable].Description] SHOULD show the related table data. In fact, you can pop-up an alertbox to examine [SalesTable], see that it is correct, show the text box (which shows no data), then popu-up an alertbox again and see that [SalesTable] is still defined.

READ THIS CAREFULLY: Meanwhile, a simple text label right next to all this going on that is defined as [db.[SalesTable].Description] will show the correct table data the WHOLE time.

Trust me. This has NOTHING to do with table open timing. This has EVERYTHING to do with how text boxes parse and interpret the variable name specification. NOTHING ELSE.

And if it was a case where the text input box variable name must be literal and complete at startup time before any startup command is executed, then we are right back to the conclusion that text input boxes handle variable names differently than any other object.

The problem now arises that as you open the table and navigate the records, [SalesTable] does not change, hence there is no "trigger" to sync it in your Text Entry tool/object.

Again ... no no NOOO. Embrace this: [SalesTable] is ALWAYS defined and constant. it is NOT NOT NOT tied to table values or anything else dynamic. It is ALWAYS ALWAYS ALWAYS populated by a table name. I may CHANGE the table name in the ideal world, but full test of this issue can be seen without EVER changing the value of [SalesTable]

Years ago, when I ran into this problem, it was with the Simple Text tool/object ... i.e. specifying something like "[thisDB].[thisTable].[thisField]" as the value to be displayed in the object's space.

Are you saying that you get expected results with this tool/object ?

YES!!!!! As I have said a bazillion skillion times, EVERY object works AS EXPECTED using field and table names made from variables >>>EXCEPT Text Input Boxes.<<<

Given the variable defined at startup; [SalesTable] which contains a LITERAL string of "Sales_2014", THEN:

EVERY dbp command will accept [SalesTable] as a valid table name input. EVERY ONE!!! That means you can open, close, navigate, copy, drop or otherwise work with the table as needed any time without fail.

Given a field name specification like [db.[SalesTable].fieldname], THEN:

EVERY and I mean ab-so-freakin EVERY object besides the text input box will use the field specification and operate as expected. Buttons work, grids work, simple text labels work, scripts work. EVERYTHING WORKS as expected and changes with navigation of the table as it should. But not text input boxes.

THINK ABOUT IT. Given the above truth, it points to the obvious conclusion that ONLY text input boxes have a fundamental difference in the way they interpret the variable name to work with. Think of it in simple terms. If you have 100 objects that use the same variable syntax, but only one of them does not work, then guess what? The problem is with the one that doesn't work, NOT the code syntax.

I believe that "under the same circumstances" this will happen in other tools/objects ...

Sigh ... no, it doesn't happen to anything but the text input boxes. Read everything above back to the OP.

Can you provide a detailed example of where such a problem does NOT occur ?

No ... not so much. I can, but ... no. It does not occur in every object and command except the text input box. Again, see above.

It is not hard to replicate if you have a database file to work with.

1) Define a variable to hold the table name.
2) Open the table using the variable.
3) Create objects and commands that use the field syntax [database.[tablename variable].fieldname]. For example, make a form page with a grid using the table name variable. Add a text label using the field syntax. Add a text input box using the same field syntax.
4) The grid will work, the text label will work, the text input box will not.

Example created.

I think this is a programming problem in NeoBook. Or there is a reason that text input boxes must have a different way of handling variable name specs. I was hoping Dave would chime in here and say.

I am still going to solve this with virtual tables. I have proven to my own satisfaction that this is a text input box problem and not a code syntax problem. Given that, I cannot solve it with code, so virtual tables is the way to go.

Thanks.
User avatar
Enigman
 
Posts: 314
Joined: Tue Apr 12, 2005 3:57 pm
Location: Foothill Ranch, CA

Next

Return to NeoBookDBPro

Who is online

Users browsing this forum: No registered users and 1 guest