I am running OI3.5. Development system on my PC… a runtime deployed

to the network. I deploy updated forms using the check-out procedure

which seemed to have been working O.K. Now I deployed a form that worked fine on my development system but on the runtime some

buttons didn't seem to work quite right. I changed my oengine.exe on the runtime to my development oengine.exe, started form design… and

found that many scripts for the click events of numerous buttons

were not there in my runtime form…. can this be corrected???

is it a bug?????? heellllppppppppppppppp. P.S. I'm deploying all entities associated with the forms…

Steve C.

When you 'deploy' the window with the check out option, I think you also need to check out the events themselves. They are located under a different repository entry.

Jeff

Jeff,

I am checking out all "USES ENTITIES" also.

Also, if the runtime has the WINDOW entity QBFABS with

a script in the prior FORM, and I've cleared that

script in a new development form I'm deploying, the

old WINDOW entity QBFABS with the script in the runtime

remains after the new deployment and messes up the

execution of the form.

Steve C.

Are you deploying the source as well as the executables for the forms? Usually just the executable is needed.

Have you verified in the repository that the executable versions have the executable window/events listed as 'uses' or 'used by'? Maybe something is being missed there.

Jeff

Jeff..

I am deploying the source as well as the executables for the forms?

I have verified in the repository that the executable versions have 'uses' or 'used by' for all events. Just can't figure this one out.

I've been updating my runtime with the check-out deployment since

OI3.5 was released with no problems….with some very extensive

scripts in quickevents for numerous forms….maybe I just need to

take off to the Cayman Islands for a couple of weeks and forget about

my end users…. yes….yes…Yes…YES….that's the ticket..

Oh… sorry about that…I guess I got a little carried away…

get carried away ….maybe get carried away to Belize…yes….Yes.. …YES……………….

I think the problem is that your slightly misunderstanding how event chaining works.

Everything's great on your system, since the window compiler knew to kill the event you had deleted. However, on the runtime system, it didn't know the event no longer exists. So, when the system checks for available events during runtime, it finds the 'deleted' event and executes it.

What you'll need to do is issue a REPOSITORY 'DELETE' call to remove the missing message. Don't really know of any easy way to do this.

I know that when RTI does upgrade disks, they have a series of programs that creates lists of entities in a virgin old version and a virgin new version. They compare the lists of entities and create a table of entities to add and a table to delete. These then get placed in the %PROCESS% record. You might have to do something similar with your product.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron,

Thanks…. That looks like it may be the major reason for

my problem. It would be nice if there was an easy way to

'kill' the deleted events in my runtime system, but it

looks like I will have to do that manually each time.

I guess when I start updating systems off site I will

need to have some RBASIC subroutine run during the update

that will "DESTROY" specific REPOSITORY Entities. Any

other suggestions you might have on making this easier

would be greatly appreciated.

Thanks… Steve C.

Steve,

It would be nice if there was an easy way to 'kill' the deleted events in my runtime system

It is as simple as issuing a Repository("TDESTROY") against the window/exe before you copy the new one in.

<code>
declare subroutine Set_Status, Repository
$insert Logical

Set_Status(FALSE$)

EntID=@appid: "*OIWIN**": FormName
Repository("TDESTROY", EntID)
Set_Status(FALSE$)

EntID=@appid: "*OIWINEXE**": FormName
Repository("TDESTROY", EntID)
Set_Status(FALSE$)

</code>

Cameron Purdy

info@revelation.com

Cameron,

Thanks for the info. That should do it.

I can find help and doc info on the "DESTROY" message,

but nothing on the "TDESTROY" message. I am assuming

that "DESTROY" deletes one entity at a time while

"TDESTROY" does a "Total" delete on all entities

associated with a Form.

Thanks… Steve C.

"Tree Destroy"

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Does "Tree Destroy" remove all "Uses Entities" or just orphaned ones?

dbakke@srpcs.com

SRP Computer Solutions

I'd always assumed all uses entities - I'd always hoped just all events, not popups, msgs etc etc. Perhaps we ought to play and see?

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Don,

Does "Tree Destroy" remove all "Uses Entities" or just orphaned ones?

TDESTROY is a special message for OIWIN and OIWINEXE types to clean up the "entire" form/event collection. If you TDESTROY an OIWIN, it also deletes all related OIEVENT entries. If you TDESTROY an OIWINEXE, it also deletes all related OIEVENTEXE entries. Additionally, if you TDESTROY an OIWINEXE, it in turn TDESTROYs the corresponding OIWIN.

Cameron Purdy

info@revelation.com

Cameron,

Will POPUPS and Subroutines or other processes called

by a quickevent from within that FORM also be deleted??

Thanks..Steve C.

Sounds cool - thanks - just what I hoped!

amcauley@sprezzatura.com

Sprezzatura Ltd

World Leaders in all things RevSoft

Steve,

Will POPUPS and Subroutines or other processes called by a quickevent from within that FORM also be deleted??

No. For OIWIN, just OIEVENT and for OIWINEXE, just OIEVENTEXE plus TDESTROY on the corresponding OIWIN.

Excerpts from internal procedure documentation follow:

<code>
compile function repos.oiwin..tdestroy( charstr message, integer entid)
...
 PURPOSE    : T-Destroy method for OIWIN objects
...
 THEORY OF OPERATION :
     1. Executes DESTROY for its own OIEVENT subs.

compile function repos.oiwinexe..tdestroy( charstr message, integer entid)
...
 PURPOSE    : T-Destroy method for OIWINEXE objects
...
 THEORY OF OPERATION :
     1. Executes TDESTROY for its own OIWIN and DESTROY for OIEVENTEXE subs.

</code>

Cameron Purdy

info@revelation.com

Out of habit, I always click the Tree button when deleting a window and I've never had it kill a popup or program or any other item except the window and the events. This goes back to like the early 2.0 alphas as well, so I'm 100% confident that it does not destroy anything else.

In fact, I'm so confident, I'd stake Andrew's life on it.

apk@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...