Here is my wishlist
There is a WHEN-FORM-NAVIGATE trigger which fires in the form we navigate to, but no trigger that fires in the form we navigate from.
It should be very nice to have a grid-object to present data in a block
More attributes available, like set_tooltip.
Native support for the same graphics as in JDeveloper
Support for Java webstart
Here is another suggestion....
This is a must have improvement that has afflicted forms since the beginning of time.
Create a new trigger, call it whatever you like, that works just like key-commit, but also gets fired when the user presses "yes" to the "Do you want to save the changes?" dialogue. Currently all code in key-commit gets bypassed when "yes" is pressed on the dialogue. You have no idea how many forms I come across and have to fix that have lots of key-commit code that does not get executed when the user makes changes, presses exit, gets the "Do you want to save the changes?" dialogue, and presses "yes'.
Newbie Forms Programmers typically put lots of code that validates entries and changes form field data in the key-commit trigger. This is ofcourse not a good idea.
1. One thing that would really make my job easier as a developer would be to show "date last updated" for each package, procedure, function and trigger within the oracle form. This was something available in PowerBuilder and was extremely useful when comparing versions or determining what portions were last updated.
2. Something needs to be done about the 40735 errors. It appears that when Oracle developed 10g they lumped every conceivable error under the one code. This makes it extremely difficult to debug. We need clearer- self explanatory debug codes.
3. Allow the user to open more than one edit window at a time. We can do it now by doing searches but this should be easier to do. For example, we can pin a property, why not be able to open a procedure package, pin it, then open another package in a separate edit window.
our power users suggest the following features for the future Forms releases:
- Give the opportunity to choose Forms as a Client-Server-architecture aside WebForms
- Integration of GIS like Google-Earth or comparable services
- Dynamic adaptations like Itemsizing and Fontsizing when the window is resized at Runtime
- The function "LOV-Button in Multirecord-Block should control the corresponding correct record without additional coding if Mouse Navigate = FALSE
- Better realisation of the LOV: Recommendationlist as it is realized by google or ebay
- Realization of Tooltips in Context of a Record
- Improvement of the Support of keys like ESC, Backspace by corresponding trigger
- Properties of Spreadtables by Multirecords (integrated Sort-Handling, Exporthandling, ColumnReorder and the possibility to save this as a preference of the user)
- simple drawing functions for figures and lines and circles
- Undo-Function which can be accessed by CTRL-Z for Textitems
- Realization of a BLOB/CLOB-Handling between Client and Server - Filehandling!
- Integration of WebutilSample into Forms, give the cance to use PLL
- Make the footer accessible not only for messages
- the inner head of a window should be minimized if the function maximize is selected (realize more space)
- codebased realization of new items
I believe Oracle Form is the best tool to develop Database Application in Oracle Database. The weakness I see in Oracle Forms 10g may be its deployment as Java Applet. Java Applets are to be downloaded in the client browser, that's why it's not lightweight as PHP/ ASP/JSP scripting technology. So as a true web application it is not really handy.
Oracle provides JDeveloper/ Apex to accomplish that. But JDeveloper is very complicated to understand and Apex is rigid and you have little freedom on your user interface design, you cannot design a page as freely as you do in Adobe Dreamweaver for PHP. We as Form developer want oracle to develop a new development tool with following features:
1. Language will be PL/SQL.
2. There will be simple drag and drop interface design.
3. It will generate HTML/JSP page so that it can be light weight.
5. Will have good old simple look in Form Development (JDeveloper is so complex and Apex is so shy in revealing it's features) while having same even better inner strength of developments.
6. Will require no client side tool like jinitiator or jre
7. Better and easy or even no use of web_util package but still accomplish file/image/spreadsheet access
Hasan Al Mamun
When in the property pallete change the Edit->Inherit Property behavior. Currently if there are 2 or more properties with a red x (not inherited) the only way to re-inherit is to click on each property and the click edit->inherit property. Allow us to select multiple property items and then just click inherit property once.
Here are my two suggesstion :) most of them have beed added before.
a) When we run any process in oracle forms like in this process if we are running LOOP or any process. Then forms get stucks till it finishes the processing. So, in this case we can not add the Progress Bar. Because when user bymistakely minimize the window then he can not the real picture of form while processing. And also in 10g i noticed one thing if i create timer then my pointer alwasy seems like working or any process is running.
b) In the LOV there should be FILTER option for detail block, I mean the value we have choosed then LOV should eliminate that values. Because i saw many peoples ask about this. We can do this by code but it would be easier to choose filter from list.
Why do the sourcefiles have to be in binary format? Why not simply write the sourcefiles down in a readable XML format?
To my mind this would have several benefits:
- good bye jdapi, hello XML api: Oracle wouldn't need to support or enhance it's jdapi or any api to batch manipulate the source files when everybody can write his own XML API in the language he is most comfortable with
- no limitations for the API. All properties are in the textfile, and can be accessed. It doesn't matter if it's a form, a menu or a library.
- good bye stone-age Forms Builder: You have this very nice IDE called JDeveloper in house; why not use it's capabilitys and write a simple plugin for (XML-File) Forms? Heck, I could even write my own JDeveloper or Eclipse plugin if the provided one doesn't satisfy me. Or I could even use good old vim for editing forms...
- good bye to all problems related to those binary files...fmb => fmt => fmb? not anymore. The replace ';' with ';' trick? I don't think so.
- I simply couldn't live without a version control system like Subversion. Thinking back when I put our software projects under version control it took me a hour to import a java project into subversion (and this hour includes the setup of the server from scratch) and get people to work with it. It took me weeks to write ant scripts for compiling the local working copy, writing scripts for merge of conflicted forms or diffing forms so one get an idea what he has done and $much_more_stuff before I even thought about putting the forms application under version control. Things I wouldn't have needed if the forms compiler wouldn't change the sourcefile so the subversion client marks them as changed. I also could have used a simple text compare too for diff/merge/blame.
- Oracle could just dump the whole codebase for writing the binary forms from forms builder or with jdapi or the c api for new forms versions. No need to support / maintain / enhance it anymore. It cannot be simpler as a XML API. Also there is no need to support / maintain / enhance Forms Builder if this job is done with a JDeveloper plugin. The whole layout editor already exists there. I'm sure the syntax highlighting for PL/SQL is already implemented (SQL Developer). Intellisense - everything there. Support of version control systems - already implemented. As JDeveloper is (to my mind) a very nice IDE, why not use its capabilities?