I'm about to take on the task of moving my Arev app to OI.

I have a few questions first.

My application involves several modules that are purchased seperately for different departments in an orginization. Each module runs alone or in harmony with other purchased modules. I rejected the multiple application/account approach for each module because sometimes one person needs access to multiple modules simultaneously.

My solution in AREV was to create multiple module-system tables, - i.e. WINDOWSa, MENUSa, POPUPSa, REPORTSa, SOURCEa, OBJECTa, CODESa - and place them on seperate subdirectories for each module. This allowed both WINDOWSa and WINDOWSb, for instance, to be attached at the same time. Easy to add a module. Easy to update.

It appears that in OI, I'm screwed. I'm told that all object code belongs in SYSOBJ. I'm guessing that goes for Windows(forms), Menus, etc. as well. If I'm offbase, please let me know.

The question is: I can't be the first guy this has affected. How do you manage multiple modules in OI? Is there a code in the sepository that can be set?

thanks (trying to get my mail address in the signature)

[email protected]

Paul,

Both the RDK and the Check In/Check Out programs in OI allow for you to prepare additional modules for later installation. What you need to do is write in your application a procedure/window that will check the upgrades into your app, so instead of using a different VERBS file you copy the rows into SYSOBJ etc… and make the necessary repository entries.

John Revelation

John,

Thanks for the quick response. I go to the kitchen, get a cup of coffee, play with the wife a minute, and come back to find your answer. Cool!

(BTW, when I try to re-read your response at the bottom of this page, I get an error 500 from your Domino server.)

] Both the RDK and the Check In/Check Out programs in OI allow for you to prepare additional modules for later installation. What you need to do is write in your application a procedure/window that will check the upgrades into your app

Yes, but how does one isolate which item belongs to which module? Is there a means of setting a global-per-module build id?

Thanks

Paul

All i have to do is "write in your application a procedure/window that will check the upgrades"

There's really not. You could use one of the fields in the repository, but it would be up to you to maintain this. A better idea might be to have MOD1_ACCTS MOD2_ACCTS or something like that. Any prefix that means something to you. At least you can always find things, and they're all clumped together in the open dialogs (if you think that's a good thing).

[email protected]

Sprezzatura Ltd

We too have multi-module applications in OI.

Using Inheritance it allow modules to be kept below a general application where the tools for the modules may be kept and accessed by each module.

Be careful about creating one application for each module as if you deploy these into a multi-user environment with a SDP, each application will require a seperate SDP to keep Revtech happy with the licencing arrangements.

Paul,

Depending on how your application is licensed, there is another alternative. Each window (or some other unit of your application) can either be enabled or disabled. As a window is created, it can check if it licensed, and if not, tell the user. Likewise, menu items that launch windows that are not licensed can be enabled or disabled by determining if the window which would be invoked is licenced or not.

This allows you to ship the same application to all customers but selectively disable/enable portions of the application based on license data. The customer can then license additional portions without requiring an upgrade. (It can be as fancy as you are willing to make it.)

Cameron Purdy

Revelation Software

] Be careful about creating one application for each module as if you deploy these into a multi-user environment with a SDP, each application will require a seperate SDP to keep Revtech happy with the licencing arrangements.

This, I became aware of with my AREV app, is another good reason for the "multi-module" design.

As far as inheritence and tools, that was easily handled by putting the tools in the global account. Maybe I'm not seeing something, but I don't see what the big whoop is about inheritence. I suppose if I customized each customer's application, as some do, this would be a help. If I did this for the several hundred clients I have, I would need more than just little ole me running the show and I'd have to work more than 3 hours a day.

Paul

Cam,

First off, thanks for taking the time to respond.

] Depending on how your application is licensed, there is another alternative. Each window (or some other unit of your application) can either be enabled or disabled. As a window is created, it can check if it licensed, and if not, tell the user. Likewise, menu items that launch windows that are not licensed can be enabled or disabled by determining if the window which would be invoked is licenced or not.

So, each window/menu has a pre-init process that is run? This process would check the user against a list of module-windows/menus to grant access? It seems this shifts the burden from the developers' system to each customers' system.

It still does nothing for the problem of identifying each modules' components. Do you concure with Aaron that the only way to segregate a module's menu/window/process is prefix each name? Such as MODnWindowName, MODnMenuName, $MODnProcessName?

What would it take to identify something like this in the Repository? Wouldn't it make sense to identify something this here? Off the top of my head, I would like a MV field that I could use to flag an item to be included in multiple modules. This way, I could compile/check in/check out/whatever each module by itself.

Paul

Paul,

So, each window/menu has a pre-init process that is run?

Assuming you were to do it on the window level, I would suggest creating a promoted CREATE event (one that applies to every window). To do this, you need 3.5 with the Event Designer tool because you must enforce the CREATE event so that the promoted event fires whether or not the window itself has a CREATE event.

Step 1: Figure out how you can tell if a window is licensed or not.

It still does nothing for the problem of identifying each modules' components.

You must do this yourself, as you don't want the rest of the world to know how it works. In my example, I will have a list in SYSENV called UNLICENSED which is an @fm list of windows which are NOT licensed. (It isn't creative, but it suffices for the example.)

Step 2: Build a function which checks if a window is licensed or not. I will call mine IsLicensed().

<code>
function IsLicensed(Window)

$insert Logical

common /license_info/ initialized@, unlicensed@

if initialized@ else
  open "SYSENV" to f then
    read unlicensed@ from f, "UNLICENSED" else null
    initialized@=TRUE$
  end
end

locate Window1,"*' in unlicensed@ using @fm setting Pos then
  bLicensed=FALSE$
end else
  bLicensed=TRUE$
end

return bLicensed

</code>

Step 3: Build a function which will become the promoted create event. My application is called "TEST", so I named the function Test_Create. Note that the parameter list is identical to the CREATE event in the Form Designer.

<code>
function Test_Create(CtrlEntID, CtrlClassID, CreateParam)

declare function   IsLicensed
declare subroutine End_Window

$insert Logical

if IsLicensed(@window) then
  Continue=TRUE$
end else
 * display license message here!
  End_Window(@window)
  Continue=FALSE$
end

return Continue

</code>

Step 4: Promote the create event. Basically, this means that you put the object code into the SYSREPOSEVENTEXES table with a special key. The object code is compiled into the SYSOBJ table with a "$" prepended and a "*"+ appended. The destination is the SYSREPOSEVENTEXES table with a key of "*..OIWIN*". Here is how I did it in my TEST app:

run copy_row "SYSOBJ", "$TEST_CREATE*TEST", "SYSREPOSEVENTEXES", "TEST*CREATE..OIWIN*"

Step 5: Enforce the create event. Go to the UI Workspace, choose Tools, Design Events. Select the window icon (it is the default one selected when you go in), select the CREATE event, and set the Enforce value to "Yes". Save and close.

Step 6: Log out and back in to insure all caches are clear.

Step 7: Recompile all of your windows. This is necessary because the "enforce event" flag is used at window compilation time to optimize the "event execution plan" for each window. (It sounds fancy, but basically it is just meant to minimize the amount of DDE from PS to the engine and also to minimize I/O in the engine.)

Easiest way is to select SYSREPOS or SYSREPOSWINS, take the ones with your app id, and call Repository("COMPILE") for each entity id. Perhaps something like:

<code>
function RecompileWindows(void)

declare subroutine Send_Info, Set_Status, Repository, V119
declare function   Get_Status

$insert Logical

open "SYSREPOS" to f else return "Error opening SYSREPOS"

select f
eof =FALSE$
List="

loop
  readnext EntID else eof=TRUE$
until eof
  App =field(EntID, "*", 1)
  Type=field(EntID, "*", 2, 2)
 *", 4)

  if App=@appid and Type=OIWIN*" then
    Send_Info("Compiling ": quote(EntID): "...")
    Set_Status(FALSE$)
    Repository("COMPILE", EntID, TRUE$, TRUE$)
    if Get_Status(Err) then
      Send_Info("Error (": Err: ") compiling ": quote(EntID))
      List := EntID: @rm
    end
  end
repeat

if len(List) then
  Err=FALSE$
  V119("S", "", "A", "L", List, Err)
  swap @rm with \0D0A\ in List
  Ret=Errors occurred compiling the following forms:": \0D0A0D0A\: List
end else
  Ret=Success."
end

return Ret

</code>

Run it from the System Monitor, like:

Run RecompileWindows

If you are wondering how I knew what to pass to the Repository function, see this old discussion thread.

One last thing: If you have a create event on a window that returns 0 and does not call Forward_Event, then the promoted event does not get called! The "return 0" at the end of an event means "don't execute the rest of the event chain". I suggest that your create events do this:

<code>
call Forward_Event(CreateParam)
* whatever code you already had
return 0

</code>

(If a window doesn't have a CREATE event, then the promoted event will always be run because we enforce it in the Event Designer.)

Cameron Purdy

Revelation Software

It could just be that Cam is smarter than me, but I would have done all that a bit simpler.

I would have had seperate menu options for each module. During the create event, check for the module, by seeing if a specific string exists in a resource file or a window exists somewhere, then enable or disable the particular menu or buttons.

If it's not enabled, they can't get to it.

You could choose to make them visible or invisible, but the enabled disbaled way leads to the following:

Customer: Hi, yes, I can't get to the Drerd module.

You: Oh, that's because you haven't purchased that module.

Customer: Please, let me send you money so I can go to Drerd.

[email protected]

Sprezzatura, Inc.

Aaron,

It could just be that Cam is smarter than me, but I would have done all that a bit simpler.

Or (more likely) it could be that Cam has been looking for a good excuse to provide a step-by-step example of promoted events!

Cameron Purdy

Revelation Software

View this thread on the forum...