Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 08 APR 1998 08:30:33AM Richard Cauldwell wrote:

I tried this in the WORKS section but didn't get a response….

Copyform allways returns the error REP 310 "TEXT", (Unable to find the dictionary for "TEXT") and the form does not compile nor can I open it in the form designer. Viewing the records of the original form and the copied form in SysReposWins shows that they are very different, where the table name appears in the original form the word TEXT appears in the new form. Looking through the source code it looks as though it's the Respository Write routine that isn't writing the new form correctly.

Does anyone know a fix for this ? If not , how do you copy forms between applications quickly ?


At 08 APR 1998 11:51AM Tracy Graves wrote:

Richard-

Well, copying forms from one application to another isn't a "quick" thing, simply because there are so many places where the appname is a part of the record information for the form. Basically the Copyform wizard is attempting to locate all this info (form, events, controls, and whatever else) and make row copies in all the appropriate places with the new AppName embedded.

This is probably why this utility is on the knowledge base with source rather than being packaged with OI.

I've never used it successfully, but I'll try it again and see if I get similar errors.

Tracy Revelation


At 08 APR 1998 07:12PM John C. Henry wrote:

Richard,

I tried the following fix to the COPYFORM procedure and it appears to fix the problem.

The problem is in the 'ParseCtrl:' subroutine. Search for the line:

'* store the converted quick-events' followed by

'Ctrl=QInfo'

Immediately before these lines add this line:

'convert @fm:@vm to @svm:@tm in Qinfo'

Recompile and it should work. I tried a conversion and the resulting window comes up in the form designer without the '…TEXT' error. I have not examined the converted window much beyond that at this time.

John @ J.C. Henry, Inc.


At 09 APR 1998 12:37AM John C. Henry wrote:

Richard,

Some additional fixes to COPYFORM:

Locate the following lines in the stored procedure:

Bmp="

if len(EntID) then

Test=@appid:"*": field(EntID, "*", 2, 3)
Set_Status(FALSE$)
Rec=Repository("GET"), Test)
if Get_Status() then
  Set_Status(FALSE$)

…..

Change the line "if Get_Status() then" to "if Get_Status() else"

do the same in the following section of code where the icons are converted. I have tested both this patch and the one in the previous message and they work. (I'm fixing the problems as I find them…)

John @ J.C. Henry, Inc.


At 09 APR 1998 07:21AM Cameron Revelation wrote:

John,

Change the line "if Get_Status() then" to "if Get_Status() else"

Are you certain about that? I believe the "then" is correct.

Cameron Purdy

info@revelation.com


At 09 APR 1998 10:39AM John C. Henry wrote:

Cameron,

You are correct about the 'Get_Status() then' statement.

The problem is that the new bitmaps are being created in the target application but the subkey is left blank. Any ideas.

Thanks

John @ J.C. Henry, Inc.


At 09 APR 1998 12:53PM John C. Henry wrote:

Cameron,

The problem with the BMPS not having a sub_key was caused by BMP entities (without the sub_key) that were apparently created during test runs with the original problem in the routine.

Removing them from the target application and rerunning the COPYFORM put the correct BMP's in the repository.

Thanks

John @ J.C. Henry, Inc.


At 13 APR 1998 08:30AM Richard Cauldwell wrote:

I've been off for a few days, so haven't had time to come onto the forum. Just wanted top say thanks for all the help.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/2052de2d691a607f852565e00044b73c.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1