Hi All,

I need to read a record into form1 then click a button

to start form2 and read the same record into form2.

Form1 is full of controls. Form2 shows differant info.

When I do this the way I know how, after I read the record

into form2, it won't let me toggle between form1 and form2.

I'm not sure how to get @id from form1 and use it to start form2.

HELP!

Steve Bell

Are you using Dialog_Box to start the new window?

The Sprezzatura Group

World Leaders in all things RevSoft

No.

I'm just starting a window with a quick event from the

button's click event.

Steven,

What is the reason for the two forms? Did you run out of space on the first one? Then a multi-page window might be a solution.

(A different possible solution is to use an MDI frame with the two forms as child windows, but that is a bit more complicated.)

The solution you choose might also depend on which actions should be allowed in the two forms. To which extent should the user be able to change and save the row shown in the forms?

- Oystein -

If I were doing this, here's what I'd do:

1. Make the Key prompt in the second form hidden

2. Get the Key prompt from the first form and stuff it into the Key prompt in the second form. Send a LOSTFOCUS event to this contol. This will cause the second form to read the ORIGINAL record from the first form. Note that changes in the first form will NOT be seen in the second form.

3. Set the properties of the second form to Ignore Self Locks.

Just make sure that the second form doesn't allow for deleting a record. You can get into a lot of difficulty doing this however if there are dependencies involved within the record structure itself since data written in the second form will NOT be seen by the first form (unless you program for it).

Don M.

In this case both forms were already created. Yes form1

is full of controls. Also in this case the user only needs to

view form2. Most of form1 users will never use form2 but some

supervisors need to sneek a peek at form2.

Steven,

Then Don's suggestion seems like a good one, if it's acceptable with that sneak peek being to the original record.

You can use a user CLICK event in the button on the first form to start that other form and get it to read the record:

declare function Send_Event, Set_Property, Start_Window

/* start the second form */

Form2Id=Start_Window( "FORM2", @Window, "", "", "" )

/* put the key into the key field of the second form */

Void=Set_Property( Form2Id : ".KEY", "TEXT", @Id )

/* tell the second form to do a read */

Void=Send_Event( Form2Id, "READ" )

Exchange the names in bold with the names of your second form and the name of its key field control.

My script is slightly different from what Don suggested. I send a READ to the second form. He suggested a LOSTFOCUS to the form's key control. Both will work.

If you try this the second form will come up, but preceded with a warning about the entity (record) being locked. If your users can live with this warning your job is finished. The user is now not allowed to save changes in the second form. Any attempt to do so will be met with new warning messages.

If you follow Don's advice about ticking the second form's Ignore Self Locks (in Database | Options…) you will avoid all warnings, but on the other hand the second form is now open for changes; the user can change and save records from the second form, which will reset changes done in the first form. To avoid this ugly situation Don further suggests changing the second form so the user cannot do a save. A simple way to do this would be to sabotage the DELETE and WRITE handlers of the second form. E.g, use the following code in the two events' user events:

Parent=Get_Property( @Window, "PARENT" )

if Parent1, "*"=FORM1" then

/* changes are not allowed. sabotage */

call msg( @Window, "You are not allowed to delete or save changes from this form" )

return 0

end else

/* changes are allowed sabotage. make sure processing continues as normal */

return 1

end

The user will still be able to edit the fields, but he'll be stopped once he tries to delete the record or save the changes. Perhaps not perfect that either, but probably good enough.

Note. I haven't tested all my code.

- Oystein -

Steven,

Don M.'s advice is sound and is what we do as well. However, beware of using the ID property in the second window as it will have a trailing @SVM and a 1 (this is how locking is avoided). If you have a programmatic process that uses the ID property to write data somewhere then make sure you strip this off first.

[email protected]

SRP Computer Solutions, Inc.

Steven,

Just to correct a typo and clarify some more:

Parent=Get_Property( @Window, "PARENT" )

if Parent1, "*"=FORM1" then

/* the second form was started from the first form. changes are not allowed. sabotage (return 0 will abort further processing) */

call msg( @Window, "You are not allowed to delete or save changes from this form" )

return 0

end else

/* the second form was NOT started from the first form. changes are allowed. make sure processing continues as normal */

return 1

end

Exchange the name in bold with the name of your first form.

(That 1, "*" thing in Parent1, "*" is just a twist you need in case you have more than one instance of your first form running simultaneously.)

- Oystein -

Oystein,

In the click event,

declare function Send_Event, Set_Property, Start_Window

/* start the second form */

Form2Id=Start_Window( "JIMW006.000", @Window, "", "", "" )

/* put the key into the key field of the second form */

Void=Set_Property("JIMW006.000": ".AR_NUM", "TEXT", @Id )

/* tell the second form to do a read */

Void=Send_Event("JIMW006.000", "READ" )

RETURN 1

The second form starts, the bell rings and thats it. The KEY doesn't

get there or the Read.

Oystein,

In the click event of my button,

declare function Send_Event, Set_Property, Start_Window

/* start the second form */

Form2Id=Start_Window( "JIMW006.000", @Window, "", "", "" )

/* put the key into the key field of the second form */

Void=Set_Property("JIMW006.000": ".AR_NUM", "TEXT", @Id )

/* tell the second form to do a read */

Void=Send_Event("JIMW006.000", "READ" )

RETURN 1

The second form starts but the KEY and the READ doesn't

happen.

What did I do wrong?

Steven,

Wow. I've never seen a form name with a period in it before. Perhaps that fails when you try to reference a control in that form, as you do in the Set_Property TEXT line. Usually the name of a form is something like AAAAA, and the name of a control is AAAAA.CCCCCC, with the period delimiting the name of the form to the left and the name of the control itself to the right. Now you got the key control called something like AAAAA.BBB.CCCCC. Perhaps your key control's name JIMW006.000.AR_NUM is interpreted as control 000.AR_NUM in form JIMW006 instead of control AR_NUM in form JIMW006.00. And with no key in the key control I assume the READ will result in a bell.

- Oystein -

Thanks

These are old Arev form names We keeped.

JIMWOO1.OOO

As in Job Information System\Window001.verizon 000

The next update would have been JIMW001.001 - 002 and

so on. W=Window V=Voc P=Popup B=Basic Program

M=Menu. This was are Arev nameing invension.

Never thought about what just happened.

Haven't had any other trouble using these names that we know of

un-till now.

I'll kick this around some more and get back to you next week.

Thanks

Steve Bell

Wow!!!

I've already fixed it. I forgot we changed those .'s to

_'s. That's all it was. It took me less time to fix than it did

to get loged back in and send you this responce.

Agin Thanks a lot.

It's working great now.

Steve Bell

Steven,

Glad you got it fixed!

- Oystein -

Just to add an extra flavour!

We've been doing this since Arev and early days of OI as one of the main records in the app has far too many fields for a single tabbed screen. Also we want to be able to pick and mix the screens for our different clients.

As far as I can recollect off the top of my head …

Each screen in set has a "topics" item on menu which overlays a dialog box of buttons for the available screens for the current record type (current screen disabled). This overlay can be individually configured for those screens required by individual client for that type of record.

When button clicked, gets current key (or key & browse list), saves current screen, starts new screen and passes key/browse list as create param. New screen create picks up key/browse list and does the necessary incl read record.

This also enables process to be started with any screen in set. Can also be started by another process with key and/or browse list.

In arev we just passed @record around saving it at appropriate moments, which as simple and quick - but this doesn't seem possible with OI.

Hope this helps and/or stimulates grey cells.

View this thread on the forum...