Re: Advice on Designer 6 non-table based form?

Hello Aaron, you wrote:

> He is asking for us to take a screen that has already been built in
> developer and move it into Designer because he wants to maintain it
> there. Now, this seems contrary to my understanding of what one
> typically uses designer for, and given what I know of the screen I'm
> not even sure it's possible.

Designer can do a 'design capture': read the fmb and store it in the repository.
I have no experience with it, only heard vague rumours that this does not work well if the screen is complicated.
I'd suggest to do this capture and generate the screen again. See if it works or if you can make it work in Designer. I would not know what a 'typical' use of Designer is, it can be used for lots of things and in lots of ways.

> Now, aside from the calls to the stored procedures themselves, nothing
> on the screen ties to any database objects. None of the fields are
> table based, no lookups needed, etc.
> Most of the things I have read so far assume
> you're starting off with a screen based off a table.
You can easily create a screen that's not based on a table. Create a module, a block, a canvas and a window and put some unbound items in the block. The screen you described can be build in Designer, including all the custom validation and the second page.
The question is if you _want_ to do it this way.

> My understanding of the relationship between designer and developer
> was that as a CASE tool, designer is generally used to capture
> requirements and then generate a first cut of code that gets refined
> in developer, and that anything that designer couldn't easily deal
> with is usually done from scratch in developer.
This is an interesting point. There are many ways of using Designer and everyone has his own, I think.
Designer can do the boring stuff for you like writing code for validating constraints and calling other forms. 'Normal' screens can be built in minutes. That saves time. Downside of this is that when you want something special, it can get very hard to instruct Designer to do so. I spent hours battling Generator Preferences and often wished I could work with Developer where I have much more control (I have never managed to get Designer to put a LOV at the right place, for example).

There's an advantage of having all your forms stored in the repository, no more losing fmb's and a good view of what is where.

It doesn't make much sense to work half Designer - half Developer. Suppose you create a screen with Designer based on a table. Then you add some custom logic in Developer. Then a constraint is added to the table. What to do? Generate again and lose your custom code or add the constraint's code by hand in Developer?

I quite often do my 'fiddling and testing' in Developer; once I've got it going I put the code in Designer and generate the form (you can't compile in Designer and the editor is not very good).

Designer is difficult to learn and that only pays off if you use it regularly.

Just a couple of thoughts...
Regards, Joost

--
Joost Bataille
University of Amsterdam ICT centre
www.ic.uva.nl