Is eDeveloper V10 Up to the Task?

The newly refreshed developers toolkit in eDeveloper V10 presents a very fresh, clean development interface with an easy-to-use task editor and powerful expression editor. In our continuing series evaluating the 51 reasons to upgrade to eDeveloper V10, we will now focus on fourteen enhancements made to the task editor.

17. Task Layers – Easily distinguish between Data View, Logic, and Forms definitions using the clear separation between these three main pillars of a task.

I know some of you who are currently using eDeveloper are worried about replacing Record Main. But the migration process preserves your Record Main logic as is. You don't have to change things over unless you want to – and, you can do it incrementally (which is recommended). So once you get past the usual resistance to change that comes with any minor shift in a paradigm, you will actually grow to love the new layout of your application and its visibility in the three layers of the task editor: the Data View Editor, the Logic Editor, and the Form Editor.

The Data View Editor lets you define the task's data view interface as part of the task definition. The Data View elements include source tables, fields, and range. This window replaces the Record Main and DB Table repositories from previous eDeveloper versions.

You can enter Header Rows and Detail Rows in the Data View. The Header Row data view lets you specify the data source type, define links to the data source, and declare a data source open. The property sheet shows the properties for each of these options.

Then the detail row displays the Remark, Column (when a main source is selected), Virtual and Parameter. So it provides a fairly compact view that is human readable.

The Logic Editor is used to define the task’s logical segments. Keep in mind that the header line is basically a handler and the detail line is an operation. Again very clean and compact.

The Form Editor populates an initial entry automatically for each specific task. New entries are entered automatically for each subtask. Forms let the end-user interact with the application. They contain controls that either display data options or let the end-user enter data. The Form Editor displays the form’s frame and content. You can then easily design a form by assigning form properties and selecting controls and defining their properties.

So all in all, the three layer approach to Data, Logic and Presentation (Forms) is quite coherent and neat. I like it and hears a tip: you can press CTRL+TAB to move between the three editors (but you won't be able to leave the editor if you haven't created a valid entry.

18. Hierarchical Display – Easily navigate through the data-view and logic definitions of every task using the clear hierarchical display of the new task editor.

Part of the ease-of-use then comes from the hierarchical display of your logic. Use + to expand a hierarchy and – to collapse it. You can also use the "Go To Match" function which is pretty nifty and is explained here.

19. Task Properties – View and handle all properties of a task from a single task properties dialog.

Remember, the Task Properties dialog box is going to open automatically when you first zoom into a task and can be opened again later with CTRL+P while in the Task Editor. They've packed tons of power and control in here, so spend some time to re-familiarize yourself with all the available properties settings. They are organized into these tabs: General, Behavior, Interface, Data, Options and Advanced.

20. Relevant Only Information – For efficient reading of data-view and logic the task editor hides trivial information to maintain the information relevant and concise.

Rather than just listing all information in columns, the detailed information for a row is shown when you are parked on that row. In some cases this means a combo box type of display and in others it just means the column information is only displayed when selected. This allows you to navigate based on the important identifiers and then see the details when you want them. It really unclutters the data view and logic view allowing you to work more efficiently.

21. Range Settings – Obtain a full overview of all the Range criteria defined for the task's data-view from a single Range\Locate dialog.

The range window allows you to choose from a standard eDeveloper range, a SQL Where Clause and Range Expressions.

22. Default Logic Units – Customize your studio to automatically create basic logic units for every new task.

This is an .ini setting that can save you loads of time, so pay attention. This environment setting lets you automatically create a default schema, such as Task Prefix and Suffix, Record Prefix or Suffix.

Specifically, the values for this are set in the Magic.ini with the Command Line Name: AutoCreateTaskLogicUnits The available settings are:
No (which is the default), Task (Task Prefix and Suffix logic units are entered), Record (Record Prefix and Suffix logic units are entered), or Task and Record (Task Prefix and Suffix, and Record Prefix and Suffix logic units are entered). So this is a great way to jump start the logic units in the task editor.


23. Save Program – Instantly save changes of any program while editing the program.

Nice. Can you think of a time when you really, really wanted that? How about when the nasty Microsoft Updates dialog rears its ugly head to tell you your machine will reboot in 5 minutes? I hate that.

24. Developer Functions – Create your own functions to implement simple or complex procedures that involve composite resources. These function logic units will be available to you throughout the project as a built-in function.

I think the Magic International User Group should sponsor a contest for the most creative user defined function.

25. Flexible Control Handling – Handle controls by name and achieve greater flexibility by defining the control specific logic units before the form design, utilizing the same logic unit for a control in various forms and setting global control specific logic units.

One of the control's properties is its name. This enables a robust method to refer to controls in a Class 0 form, and to refer to them in functions. The LastClicked function will return the control name. Keep in mind that the Control Name property is limited to 30 characters and trailing blanks are not allowed. Duplicate control names are not allowed, so the Copy operation for controls in the Form Editor does not copy this property.

26. Variable Change – Set super responsive logic that can respond to any manual or automatic modification of any variable in a task.

The Variable Change logic unit lets you handle the change of a variable's value. And of course it is triggered whenever the variable value is changed. You can define a Variable Change logic unit for BLOBs, vectors, and ActiveXs, but not, incidentally, for OLEs. Don't ask why. I don't know. Some things just are, right?

27. Event Parameters – Improve handling and raising events by clearly declaring the parameters that are expected by the event.

In each task you can define events to be handled in your project whenever they occur. For example, you can define an event called ‘Add Customer’. Events have
Descriptions, Trigger Types, Triggers, Parameters, Force Exit and in a Main Program they have Public Name and Expose settings. There are four parameters available: Name, Model, Attribute, and Picture.

28. Post Record Update Force Level – Easily define event handlers to be executed only after all modifications of a record are updated within a transaction.

This makes it easier to ensure transactional integrity.

29. Direct Logic Access – Quickly access and create control level logic directly from any control defined in the form editor of a task.

Simply right click on the control and choose the option to create logic. Nice.

30. Tabbing order – Set the tabbing order of controls independently from the order of the fields in the data view definition. The value of each element can be set as fixed or dynamic.

Okay, you may begin the applause. Whenever Magic shows this, developers get very happy. It's the little things in life that make the difference, you know.

31. Subforms – Implement Parent-Child displays quickly and easily at the click of a button by simply declaring the participating child task on the parent's form using the new Subform control.

One thing to remember here is that a Subform control works only with an online program, which means that the Subform will not be active for a Main or Batch program.

With that in mind, you can use the Subform control to integrate a task form into the form of another task, while maintaining the subform‘s task data handling and record cycle activities independently from the parent task. But you cannot define a Control logic unit or an Event logic unit for a Subform control.

Nevertheless, a subform offers several advantages: 1) you can park on the line of a parent task and see the details from the subtask, for a one-to-many task relation, 2) eDeveloper automatically refreshes the Subform data view according to the parent task only when passing parameters, 3) eDeveloper retains your last position in the Subform data view when you leave and reenter., and 4) a tab cycle is provided for the Subform task.

Okay, well that is probably about as much Joy of eDeveloper V10 as you can process in one sitting. So we will blog on about eDeveloper V10 in our next entry, where we will evaluate the improvements to the expression editor.