Crazy Raz's Christmas in July Wishlist

[Razumovsky]

Okay, so a few days early, but here are the things I have been wishing for lately that I want for christmas. It is a lot, but they all seem pretty achievable in the current structure and would be remarkably helpful. Also, I have been a good boy this year...

SCRIPTS

create/delete/edit table/TO/field/relationship

Pretty straight forward - script automation of define fields. Would be a tremendous help towards designing flexible and re-purposeable solutions. Probably the most difficult of my wants.

LAYOUT

View 'SampleData' in layout-field select mode (displays data from the first record in place of field names when you are selecting which fields to display in layout mode). While we are at it, it would also be great to display sample data in the fields box while defining calculations.

Tab Panels with memory ( stays on the tab last viewed on the layout in browse mode, specific to each user). Yes there are workarounds, but they are clunky.

Drop down list with values from record field:

Ability to define a field to use values from any field on the current record in a drop down list. Values would be called directly from the field, so would not have to be indexed.

Field Tab order by calculation:

ability to dynamically control the field tab order on a layout through a define calculation box.

FUNCTIONS

sort(list; sortParameter) function:

returns values in list (any field or text string)

sortParameter could be another list of values, or 0 = ascending, 1=descending

sort("Rabbit¶Cat¶Dog"; 0) returns

Cat

Dog

Rabbit

get(autoenterRepetitionNumber)

Would return the repetition for text, date, and number repeating fields so as to allow individual repetitions of an autoenter repeating field to produce different results. Would eliminate the lookup from calculation workaround.

relatedValueListItems(filename; listname )

would return the valuelist specified displaying only values from related records from the context of the calculation.

DEFINE FIELDS

-send forward/back Table Occurences.

-lock/group TO's

-show Object size in Relational Graph:

These all would function on the relational graph the same way they do with layout objects in layout mode.

-Option click and drag relationship lines to copy:

would allow relationship paths to be duplicated to an already existing TO.

-calculated context for calculations:

ability to have an expression specify the context that the calculation would run from.

I will leave out milk and cookies under the tree if that will be of any help.

-Raz

[Ender]

Before the elves start digging out their tools, I have some questions and thoughts on some of these:

SCRIPTS

create/delete/edit table/TO/field/relationship

Pretty straight forward - script automation of define fields. Would be a tremendous help towards designing flexible and re-purposeable solutions. Probably the most difficult of my wants.

I'm afraid I don't see the utility of this. Why would this be needed (or a good idea)?

LAYOUT

View 'SampleData' in layout-field select mode (displays data from the first record in place of field names when you are selecting which fields to display in layout mode). While we are at it, it would also be great to display sample data in the fields box while defining calculations.

{Shrug}

Tab Panels with memory ( stays on the tab last viewed on the layout in browse mode, specific to each user). Yes there are workarounds, but they are clunky.

Alright, this would be good.

Drop down list with values from record field:

Ability to define a field to use values from any field on the current record in a drop down list. Values would be called directly from the field, so would not have to be indexed.

I don't quite see the significance of this one. Can you site how it would be useful?

Field Tab order by calculation:

ability to dynamically control the field tab order on a layout through a define calculation box.

How's that supposed to work?

--To be continued--

[Ender]

--Continued--

FUNCTIONS

sort(list; sortParameter) function:

returns values in list (any field or text string)

sortParameter could be another list of values, or 0 = ascending, 1=descending

sort("Rabbit¶Cat¶Dog"; 0) returns

Cat

Dog

Rabbit

You don't get satisfaction from building your own CF to do this?

get(autoenterRepetitionNumber)

Would return the repetition for text, date, and number repeating fields so as to allow individual repetitions of an autoenter repeating field to produce different results. Would eliminate the lookup from calculation workaround.

Huh? What's that mean?

relatedValueListItems(filename; listname )

would return the valuelist specified displaying only values from related records from the context of the calculation.

Hmm, presumably you'd need a relationship anyway, so why not use a conditional value list? What's the difference?

DEFINE FIELDS

-send forward/back Table Occurences.

-lock/group TO's

-show Object size in Relational Graph:

These all would function on the relational graph the same way they do with layout objects in layout mode.

-Option click and drag relationship lines to copy:

would allow relationship paths to be duplicated to an already existing TO.

I can see the usefullness for tools to help organize and create TOs. But think bigger. How about multiple pages within the TOG?

-calculated context for calculations:

ability to have an expression specify the context that the calculation would run from.

I thought this was already in there (at the top of the calculation definition dialog)?

I will leave out milk and cookies under the tree if that will be of any help.

I can't make these changes happen, but I'll take the cookies (Yum).

[Razumovsky]

Thanks for pointing out the need for clarity Ender, so here we go:

SCRIPTS

create/delete/edit table/TO/field/relationship

I'm afraid I don't see the utility of this. Why would this be needed (or a good idea)?

From a developer’s point of view, this would eliminate some of the restrictions of the Separation model. For one, you could dynamically add fields to a data file without having to have access to the physical file – include an ‘add fields’ script step in your data files, and trigger it from the updated UI file that you send, using script variables to designate field names and properties/etc… It would promote the design and creation of much more flexible template files. Also, it would allow you to create a script that could render your TO graph into a more complex n dimensional space through recursion as opposed to manually doing this.

Drop down list with values from record field:

I don't quite see the significance of this one. Can you site how it would be useful?

You could dynamically define drop down lists on the fly, by just writing a calcfield that would produce the relevant values.

Field Tab order by calculation:

How's that supposed to work?

Hmmm, perhaps as a list of field names? Instead of selecting each field manually for tab order, you could select ‘Tab Order by Calculation that would pull up a calculation dialog box.

Case(isempty(firstname); “”;

“Firstname ¶

Lastname ¶

Address ¶

City ¶

State ¶

Zip”)

This would prevent the field from being tabbed out of unless firstname was filled in.

You don't get satisfaction from building your own CF to do this?

Plenty of satisfaction, but not the best results. The native FM sort mechanism seems to work much faster (or am I just imagining it?). It would be nice to have access to that tool.

get(autoenterRepetitionNumber)

Huh? What's that mean?

You can define individual repetition of a repeating calculation field to return different results using get(calculationRepetitionNumber):

getNthRecord(extend(SomeField); get(calculationRepetitionNumber))

However, autoenter repeaters will only produce results in the first field, or need to be looked up from a repeating calc field. get(autoenterRepetitionNumber) would allow each repletion of a text autoenter to have its own identity when returning values.

relatedValueListItems(filename; listname )

Hmm, presumably you'd need a relationship anyway, so why not use a conditional value list? What's the difference?

As you say, you would have a relationship anyway, so defining a valuelist from each possible context of your graph is a bit redundant as the information seems to already exist. It would cut down significantly on the total number of valuelists that need to be defined.

But think bigger. How about multiple pages within the TOG?

Yes, that would be nice as well, but I still want the others more. I have begun to layout my RG’s in three dimensions using layering to imply relational depth. It has added a lot of clarity, but I have to be careful to return each to its correct layer after I click on one. It is a hassle.

-calculated context for calculations:

I thought this was already in there (at the top of the calculation definition dialog)?

It lets you choose where to evaluate from, but I would like to write an expression that would dynamically specify this:

Case(Get(LayoutTableName)=”Context 1”; “Context 1”; “Context 2”)

Any better, EnderClaus?

[Lougee]

A small thing but I'd love to be able to define tab sets (that tab as in tab order). I frequently bounce between sample data entry, testing calculations, etc where I need (or want) to use the same layout and want to be able to limit the tab order to just those fields I'm concerned with at the time.

Right now I have to either edit the current tab order or create a new order. Either way, the 'tab order set' that I have defined is wiped out and I need to recreate them over and over and over and over...

[Genx]

I would love to be able to select individual tables for backup within a file on FM server, incremental backups etc. basically more control would be great. Then on client side - grouped relationships. Further one of the things that would be really really brilliant is if they could work in a Data Viewer into the standard Calc dialog box with a refresh button to evaluate your calculation (so as not to unecessarily trigger plug-in's in a loop - i did this once by accident lol).

[Singlequanta]

Here is MY wish list

On the define relationships view I want to be able to right click on a whole table; copy it; then go to a DIFFERENT file; and paste it

Oh...

and I want to be able to right click on TWO tables that have a relationship; copy it; and paste it..

hell, i just want to copy and paste tables/relationships between files!

Now i know that sounds simple, but i also know how incredibly complex that would be And how totally cool it would be too.

And why not extend that capability to scripts and layouts too :)

[Lee Smith]

You can copy the table now, how would this be different?

[Stuart Taylor]

Lee's right they already added copy and pasting for tables... there is even a plugin for getting and modifying the xml on the pasteboard its amazing.

I would like a very limited scriptable level of layout access.

It would not have to actually enter layout mode.

To have the ability of being able to modify a predefined object.

Move/Resize Object:

Left position

Top position

Height

Width

maybe some other controls but this would be great as a start.

[Genx]

I think singlequanta was refferring to TO's and their relationships not Tables.

[Stuart Taylor]

on second reading i you are right ... would be useful should think its coming.

[GC GYM]

From a Novice's point of view, I think it would be really handy to import a related file with it's relationships, scripts, layouts and records. I would like to take away a copy of a table, do some work on it (file and data), then replace the original table if I miraculously managed to make an improvement.

C'mon Santa. How about a 6 pack of Heiniken and an R-rated DVD?