× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Buck Calabro
>
> I started this so many times and have consistently failed to type anything
> sensible.  Continuing in that vein, I glean from your discussion
> with Booth
> that you aren't interested in tinkering how the DDS is laid out; just how
> the RPG is to interact with the chosen DDS.

Personally, I'm having a hard time with this whole thing.  The issue was in
my mind simple and specific, and instead we're jumping off into theory and
system architecture.  Forest and trees kind of stuff.

Maybe I'm just an old dinosaur, but it seems to mee there are situations
where you might want to use the same panel in multiple places.  Three
options:

1. Individual display files for the separate panels
2. Cloned record formats in multiple display files
3. One giant display file for the entire application

I'd love to hear discussion on this, but IMO option one is the best choice.
That then leaves my original three options:

1. Individual programs
2. Modules bound by copy
3. Modules in service programs

I could also probably have multiple display files in a program, but that
scares me too much.  So of the three above, what is suggested?

> I just can't see how
> ILE could
> have an impact on that decision.
>
> Perhaps leaving the display file out of the question would make it easier.
> What problem do you contemplate ILE solving that a dynamic call can't?

Leaving out display files defeats the purpose of the question.  The whole
issue was about display files in modules.  That's all.  That's it.  Simple.
Booth popped turned the discussion to vertical and horizontal
modularization, and the demise of all legacy programming techniques, but all
I wanted to know was: "Are there problems with display files in modules?"

The differences are primarily production oriented.  Multiple programs means
multiple ojbects, and that's the issue.  With dynamic calls, moving an
application from development into production means moving multiple program
objects.  With bound-by-copy modules, there's only one object, while with
service programs you have an intermediate number, depending on how you bind
the modules into the service programs.

Now, while the issue of number of objects is fairly straightforward, I
wanted to know if anyone had addressed the issue of having a display file in
a called module, and whether they'd run into any problems.  How do you open
and close it?  Do you get weird problems with, say, OVERLAY not working as
you expect it?  Or KEEP and ASSUME?  I've seen issues with borders not being
repainted on a popup window (the fields were shown, but the borders
weren't), and was wondering if that's just me.

That's all I was asking.  What are people's experiences, if any, with
display files in modules.  Nothing more, nothing less.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.