FM14 changes that actually seem to make development slower

Discussion created by Extensitech on May 26, 2015
Latest reply on Jun 9, 2015 by Extensitech

First, let me say off the bat that we love the direction taken with FM14, and the stated intent to let the developer "keep hands on the keyboard" with the new workspaces.


The items below are, I believe, unintentional consequences of other enhancements, which may reasonably have gone unnoticed among developers who are not, in fact, used to keeping hands on the keyboard already. For myself an my team, this has always been a goal. We were (and are) thrilled with the new places we can keep hands on the keyboard, but in several areas, comprising most of the items below, these unintentional consequences have actually taken a large step backwards from that goal.


I'm reminded of when the Inspector came out. The inspector is great, but I wish I still had the menu commands that allowed more granular control of changes to the selected object(s), not to mention keystrokes (and windows hot keys) that again, made it easier to keep hands on the keyboard.


The net effect is that while we've made considerable efforts to just get used to, or work around, these changes, we're still finding it much quicker to do a lot of our work in 13, coming to 14 to test, and to work with new elements like button bars. I know this wasn't the intent of the new version. Perhaps others can point out where I'm still in "13 thinking" and there are actually better ways to keep hands on the keyboard?


Barring that... am I the only one finding these things challenging and getting slowed down? I expect to have to adjust to changes, but I'm having trouble getting our speed back up, given the changes below.


These are all in FMPA14, on Win7 64-bit, but most are evident on Mac, too, or exhibit similar behaviors.


(by "type-ahead", I mean the ability to click into a list, start typing, and have the selection jump to the thing you are typing. Not to be confused with auto-complete)


In the Specify Field dialog

  type-ahead is completely disabled in the table drop-down (see Specify Script, which works as expected, for comparison)

  to click into the field list and type ahead, if the field is from a foreign table, must now type "::" first


In the script workspace

  in the scripts list, type-ahead is completely disabled once drop-down is shown

  in the script steps list, type-ahead is completely disabled

  in the script steps list, it is no longer possible to select and move multiple script steps

  in the script area, it is no longer possible to type ahead to a step in the script

  For Set Field, the two "specify" buttons share a hot key (the letter s). Also, if you have the second specify highlighted, and hit space to select, the first specify comes up.

  I'm still having trouble "letting go" of a script step when I want to get to a new line. Control + Enter works most of the time, but sometimes even that won't allow me to move on


  We have a continuing issue of scripts moving in the scripts list. It's hard to catch it happening, but we repeatedly find scripts from the list moved to the bottom of the list through no intentional effort of our own. In the pre-release version, we actually saw this with script steps in a script (!!). I myself have not yet seen this since installing the production version, but one of our other developers has.


In Manage Database

  fields tab, Table selection, type-ahead is completely disabled once drop-down is shown

  on the relationships tab, type-ahead will get to you a TO... unless it contains a "p", in which case the print dialog comes up


In Manage Custom Functions

  (this is true of some other lists, as well) Double clicking on the last item in the list causes the list to shift up one, so the wrong item is opened.


In the calculation workspace(s)

  double-clicking to select a word now breaks on underscores and colons, making this feature essentially useless and requiring (precision) mouse-drag selection. This may seem trivial, but we have eliminated spaces from our naming convention, and we type spaces before and after all punctuation in functions, precisely because this was such a time saver and enabled us to work quickly and with precision in the calculation workspace.

   whether you're going to get the old style calculation workspace or the new seems like a bit of a crapshoot

   you can now use tabs without a modifier key in the old-style calc workspace, which is great!... unless you get the new style and try to work the same way, where it requires a modifier key (control on PC)



Chris Cain