Category FormsAPI Master

Oracle Forms 12.2.1.19 is now fully supported in build 458. This build also includes a lot of bugfixes and improvements to the Analyzer tool. Now all that is left to do is adding support for analyzing PLL/MMB/OLB and RDF to get it out of beta!

FormsTool and FormsAPI Master V4.0 *Beta* can now be downloaded from our website! 

V4.0 features a new Module Analyzer tool to extract dependency information, statistics, datamodel and other useful information.
The new version is released as BETA until functionality runs stable and all the bugs are resolved.

A few notes about this release

• Anybody with a valid current license key will be able to use the V4.0 versions. 
• The v4.0 version uses a new license key format. The tools still accept V3.0 license keys (click on the link in the orange box on the right to enter your old v3.0 license key!)
• this is a beta version and i expect some bugs will still be in there
• If you find a bug then please let me know! See the "V4.0 beta" online Forum threads for more information or write me an email to support [at] orcl-toolbox [dot] com!
• The V4.0 version can be installed on the same computer as a V3.0 version without overwriting or affecting it. 

What's included in this V4.0 beta release

The main feature that got added is the new Module Analyzer tool. It allows you to extract all kind of important information from your oracle module (only *.fmb modules currently supported!) such as dependencies, data model, canvas screenshots, statistics and code and turn it all into a nice HTML report.  The extracted information can be used to gain a high level overview of your whole application system of how it's all connected together and form the basis of impact analyses as well as giving system analysts and managers the necessary information to estimate the complexities of changes. Work on this analyzer has been quite challenging and took quite a while. I almost forgot what other improvements I made to the tools, but here are are a few:

• new module Analyzer tool
• compare & search can now show the results in a flat view (often making it easier than navigating through a hierarchical view)
• compare now also does a visual canvas compare
• search got file handling features (move/copy/etc)
• syntax highlighting in compare tool
• scripts now remember parameters between runs of unsaved scripts
• scripting got a structure overview to navigate your code
• Export now uses a much more flexible templating system (based on javascript mustache syntax)
• Explorer and Comparer can now export to Microsoft Excel format
• etc

Plans for the near future

I still have some entries on my todo-list of things that i want to have implemented before the final release of V4.0 officially goes out and the analyzer tool still needs some more work (to support rdf/mmb/olb/pll).

Together with the stable release of V4.0 i plan to also change licensing and prices - currently, our licenses are for 2 years and that will change to 1 year. There will also be a bit of a hike in price (we haven't changed pricing since 2006). If you have a license that has expired or will be expiring soon and want to save some money then i suggest you purchase the renewal within the next month!

Plans further ahead

Here are a few things that are now on the top of my todo-list now:

• 3 way directory compare
• Merge functionality in compare (3 way auto merge)
• PL/SQL code beautifier 
• speed improvements (reports loading is too slow and Search is too slow)
• stability (doing multithreading and multiprocess better). Right now if you search through 500 modules and one of them causes a crash inside the Oracle Forms Open API then there is no way for me to recover from that - the solution is to have multiple processes (so only the sub-process hangs or crashes and doesn't impact our tools) but this involves some architecture rework as everything has then to be routed through interprocess communication. 

Regards,

Stefan Mueller,
ORCL Toolbox Ltd, New Zealand

Forms12c and Reports12c are now fully supported.

Build 340 of FormsTool and Build 437 of FormsAPI Master now detect Middleware12c correctly and offer access to all the new properties added in this new Oracle Forms release. Please note that Middleware12c is only offered as a 64bit version by Oracle and hence requires the 64bit version of our tools.

Our brand new Version 3 rewrite of our tools is now officially out of beta-stage and has been released.

It has been a long journey to get it all done, but it's finally done! The V3.0 is a complete rewrite and was needed to support the new 64bit versions of Oracle Forms. I took the opportunity during the rewrite to drop a lot of old legacy code that was hard to maintain. Some of you might miss some old feature here and there (no more propertyset filters, no database compare, etc) but dropping those features helped to clean up and consolidate the code base considerably. The architecture behind the product has been completely reworked and is now much more stable and less buggy.

I am excited about the future of our tools and look forward to implement a lot new features and enhancements over the coming months!

The long wait is finally over. FormsAPI Master V3.0 Beta has been released as 32bit and 64bit version. Customers have been waiting a long time for the Forms11gR2-64bit support and finally it's here!

Script engine breaking changes

The script engine had to be replaced (didn't get the old engine to work under stable under 64bit) but thankfully there aren't many breaking changes that would cause problems porting scripts from V2.0 to V3.0. Porting the collection of demoscripts only required changes in about 4 scripts and all of them have been minor:

• datatypes : the new scripting engine only supports number / varchar2 / datetime / boolean / variant as base datatype. The "char" datatype will have to be replaced with the varchar2 type in scripts!
• variants that have been used for OLE-Automation (using winword/excel/etc) still exists. but in order for variants to have invokable methods/properties the new "ComVariant" datatype has to be used (see the new ole_winword/ole_excel demo scripts!)
• Customers that have used external units (to move commonly used code outside the main script) will need to add a "uses orcl;" line in the unit. The "ORCL" unit contains all the helperfunctions/classes and it looks like the new scripting engine doesn't automatically add this global library to all source code units in a project. I expect to have this fixed in one of the upcoming versions. But till then you got to use the "uses orcl;" workaround as shown in the unit_tutorialinc.p2s script.
• Inline procedures/functions can no longer be declared inside a function declaration. Workaround is to move them from before "begin" keyword to after (so that the function declaration is inside the begin..end code. Looks strange but works. I expect to have that problem solved in the near future.

Probably there will be one or two other minor problems creeping up when the new script engine will get tested against a vast collection of scripts written by customers. But so far i am very pleased with the new engine.

New PL/SQL grammar

The new script engine architecture also allowed me to easily change some of the grammar. What this means is that many things have now become much more similar to PL/SQL grammar (while still keeping the old PASCAL grammar intact and supports). Following things are now possible:

• procedure declarations are now 100% pl/sql compatible. The "IN OUT NOCOPY" keywords are supported as in "procedure MyProc(p_test IN varchar2 DEFAULT 'abc') IS BEGIN NULL; END;".
• function declarations are also 100% pl/sql compatible, with the RETURN keyword as in "function MyFunc(p_test OUT varchar2) RETURN boolean is begin return true; end;"
• for-loops also got implemented : "for i IN REVERSE 1..10 loop begin null; end;" - please note that the "begin..end" is still as in pascal and that the "loop ... end loop" syntax still won't work. There are technical reasons for that - i can't implement the loop..end loop without breaking compatibility to older scripts. Currently the "for x in .." loops also don't create an implicit variable by that name (an explicit variable is still required.

Plans for the near future

I still have some entries on my todo-list of things that i want to have implemented before the final release of V3.0 officially goes out. Lot's of small stuff, but also some bigger items such as: 

• script debugger (with step in/out/over and breakpoints, variable watches and callstacks)
• Unit wizard (it's one of those features that is very handy but so far hasn't been much used by customers)
• begin .. exception ..end syntax should be doable to be implemented
• code folding and background-compilation would be useful features.

This about sums it all up - if you encounter any issues or have any suggestions of features that would be useful then please contact me and let me know!

Regards,

Stefan Mueller,
ORCL Toolbox LLP, Japan