Moving several fields at once under Define Fields?

[wookie]

I have a pretty tough project here. One of my FM files has about 500 defined fields. As you can imagine finding a field in the Define Fields window is a nightmare, which is why it is important to me to keep things sort of grouped. Unfortunately whenever you have to duplicate a bunch of fields, they always get added to the very bottom.

Two questions:

a) Is there a way to duplicate one or multiple fields in such a way, they the dups appear right below the originals (instead of the bottom)?

: Is there a way to hilite several fields and move them at once? Rearrange fields one by one and having to scroll through hundreds of other fields really drive me nuts!!!

I tried all kinds of keyboard combinations, but found no solution to this problem.

[LaRetta]

Hi Wookie,

I don't believe you can drag several fields at once nor duplicate them and have them appear right below the originals.

You can view (sort) by Field Type (look top right). Some Developers add an underline or 'z' at the beginning of their calcs and globals and then view by Field Name, but it's the same principle as sorting by Field Type.

Or ... if you have 500 fields, you might be due to re-think your design. Rarely does a db need that many fields. Many could probably be split into a related db. But, if nothing else, you can sort them a bit easier if you use the above ideas. Regardless, mapping to such a db would give me an instant headache. I sympathize. And I think I'd be looking really hard at redesigning it.

Cheers,

LaRetta

[Anatoli]

In my "so-far-the-best" template which was start for big system for quite large ($60 million) company we had 258 maintenance and general functionality fields.

All the proper routines and global fields where there.

Because all the maintenance fields where prefixed with za_ zb_ and so on, they parked automatically at the bottom.

Newly added fields had also some logic in naming, so after we added field we just resorted the fields by name and everything was all the time in proper place.

Then we just create copy of template, added the fields which where required for data and all basic things where there.

I guess the largest files where with 300-400 fields.

I would agree that you have way too many fields and you should think about your relation design more thoroughly. But maybe we are both wrong

[fishma]

I use a naming convention which works great for me... This format groups all my fields together when sorted by name. In files with as many as 75-150 fileds, I have no problems finding the fields I want. You should come up with a naming convention of your own to aid you in your development.

t_ = text fields

n_ = numeric fields

d_ = date fields

m_ = time fields

w_ = container fields

s_ = summary fields

g_t_ = global text

g_n_ = global numeric...

c_t_ = calculation (result text)

c_n_ = calculation (result numeric)

[LaRetta]

Hi Fishma,

I agree naming conventions are important. But I name them 1) What is Type (global, calc etc) and 2) Whether they are number, text, etc. only because it's irritating when in a script box that I don't know whether I need TextToNum, etc.

A simple View (sort) By Field Type would produce a similar sequence that you indicte. Naming 'conventions' appear not to be conventional at all - regardless of what the 'standards' floating around say. Until FM improves Define Fields, we'll all have to use funky ways of keeping track and organizing the fields ourselves, I guess.

And until FM improves script, export boxes, etc. we'll all need to include data types within our field names so we won't need to exit and go look up that information in Define Fields. Wouldn't it be nice if we could view the field names, Type and whether calcs are number, etc. in the same views? Now THAT would be heaven!

LaRetta

[Anatoli]

The problem I see is that everything is scattered. I like to use that separation of field types as well, but that is on second plan.

First is to separate housekeeping fields and data fields.

And even that, housekeeping should be also grouped for each task.

It will be nice to have universal standard for us all, so when we get someone else FM file we can figure some inner functionality fast.

But we probably have to wait for next FM7 or FMX and see what is there.

[LiveOak]

I've always wished that FMI would give us the ability to control field order (as in set an order) and provide for folders under define fields. Oh, well...

-bd

[BobWeaver]

I use a naming convention similar to Fishma's except that by default, any field with no prefix is a text field.

I just use a lowercase prefix letter immediately followed by an uppercase field name letter like so: gMyGlobalField -- I'm too lazy to keep hitting the underscore character.

My prefix convention is:

n - number

t - time

d - date

k - kontainer

c - calculation

g - global

id - a key field that is used in a relationship (on either the left or right side)

x - a field that must be unique

I use the prefixes in combination as necessary, eg. cidxCustomerLookup which would be a calculated unique key field

I like Anatoli's idea of using a prefix to keep housekeeping fields separate from the regular data fields. I think I'll start doing that.

[Jim McKee]

I wish soooo much that FMI would enable shift-clicking on items in the Define Fields and Scripts windows so we could move groups of items around.

One of the kewl things about hanging out here and downloading other peeps attachments is that you get a sense of the different ways people manage the Define fields window. I've started to use a mixture of the several naming conventions above.

Also, I try to keep my Globals, Data, Calculation and Summary fields grouped in the Define Fields window, with named separators between them. I don't like switching back and forth with that View by (field order) pop-up thing, because it's not available anywhere else in the development environment (selecting fields for Value Lists, Relationships, etc.). So with the groupings and separators I create, it's pretty easy to find the field(s) I'm looking for.

I also try to arrange my scripts in named groupings, e.g.:

Main Functions

Navigation (go to Layouts, related records, etc.)

Finding/Sorting

Printing

Windows (window handling)

Fields (field button scripts)

along with naming conventions for scripts, e.g.:

gL_layoutname = go to Layout

gF_filename_scriptname = call a script in another file

b|z|r|f = browse mode, zoom, refresh, bring to front

p_layoutname = print from layout

fld_fieldname = script attached to a field button

I didn't use to do any of this until I worked for a guy who was developing a monster application, and he insisted we keep fields and scripts ordered and named with some conventions. The few extra minutes it takes to get things in order before you close the Define Fields and Scripts windows results in a lot of time savings later.

Now if I could only discipline myself to write documentation as I develop

[Lee Smith]

Hi All,

Core Solutions has a pdf that is called Standard 2003 that covers has some good naming tips in it.

you can check out here

http://www.coresolutions.on.ca/Resources/download.lasso

You do have to register, but I have been registered with them for a couple years and I never hear from them.

HTH

LEe

[Anatoli]

Than you Bob

We based our naming on CoreSolution pdf. But it was older version

And tip from DevCon 2002:

Always number your scripts as first 4-5 characters!

Simple and effective!

No more scrolling through that pathetic small scroll window. Go straight to the correct number! And description can be really long.

Maybe also Relations should have number first!?

[BobWeaver]

Ah yes, the script numbering idea is good too.

A few years ago I inherited a solution where the previous "developer" had used a script naming convention that had each new script name include an ever-increasing number of asterisks, and other special characters so that he could quickly spot his latest one in a list of hundreds. By the time he was done, the scripts had names like:

@@*******!!!!Omit found set from sales file!!*******@@