Wes

If the problem is confirmed by Javier, in the meantime, here's  a workaround

1.  Save the original form in 6.5++ (FORM A)
2.  Create a copy of the form in 6.5++ with JUST the FIRST table on the
form. (FORM B)
3.  Convert ONE table form (FORM B)
4. Covert the original form (FORM A)
5. USE FORM B as your master.  When everthing is working with that first
table, add the second table to the form, and copy the controls from FORM A
for that table to the FORM B.

TEST right away to see if this removes the "jump" problem.

David

David Blocker
[EMAIL PROTECTED]
781-784-1919
Fax: 781-784-1860
Cell: 339-206-0261
----- Original Message -----
From: "Javier Valencia" <[EMAIL PROTECTED]>
To: "RBG7-L Mailing List" <[email protected]>
Sent: Tuesday, May 03, 2005 6:32 PM
Subject: [RBG7-L] - re: 7.1 Conversion Issues + 1 (popups)


> Michael:
>
> >> This will happen even if the form is created from scratch in 7.x.
>
> I have converted a few forms and created many new ones from scratch and I
> have not run into the problem where you have to essentially recreate
tables
> to get pop-ups to work properly. In most of the forms I use, close to half
> of the fields/columns on the form have pop-ups (coming from several
tables)
> as the users want to type as little as possible and they prefer to double
> click and select and as I said, I have yet to run into a situation where I
> need to re-create the look-up table(s) particularly forms developed from
> scratch...redefine pop-ups yes, redefine tables no. I would venture to
guess
> that if this were the case we would have seen a flood of posts on this
> issue, as pop-ups are very commonly used feature of forms. If you can
> reliably duplicate this condition, by all means, submit it to RBTI and
they
> will take care with their trademark expediency. I am curious now and I
will
> run a few tests to see if I can duplicate the problem.
> Javier,
>
> Javier Valencia, PE
> President
> Valencia Technology Group, L.L.C.
> 14315 S. Twilight Ln, Suite #14
> Olathe, Kansas 66062-4578
> Office (913)829-0888
> Fax (913)649-2904
> Cell (913)915-3137
> ================================================
> Attention:
> The information contained in this message and or attachments is intended
> only for the person or entity to which it is addressed and may contain
> confidential and/or privileged material.  Any review, retransmission,
> dissemination or other use of, or taking of any action in reliance upon,
> this information by persons or entities other than the intended recipient
> is prohibited. If you received this in error, please contact the sender
and
> delete the material from all system and destroy all copies.
> ======================================================
>
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED] Behalf Of Michael Moser
> Sent: Tuesday, May 03, 2005 4:57 PM
> To: RBG7-L Mailing List
> Subject: [RBG7-L] - re: 7.1 Conversion Issues + 1 (popups)
>
> Wess,
>
> I have encountered "Jumps to the second table" issue with every multi
table
> form I have converted.  Only solution I know of is to recreate the form
from
> scratch.  (If this issue does not cause a problem, you will still probably
> have to change the form from "one to many" to a "many to many" to get it
to
> work correctly if there are 3 tables involved)
>
> However ....
>
> There is one issue that will not be fixed by recreating the form.  Popup
> screens in any converted database will want to return the "Expression"
> instead of the "Return column" when using  "Expression with return Column"
> popup forms.  This will happen even if the form is created from scratch in
> 7.x.   Unfortunately the only solution I have found is to:
>
> 1.  Print a structure list of the popup lookup table (LU) (NOT the table
the
> form is based on)
> 2.  project a new table (LUTemp) from the lookup table (LU).
> 3.  Delete the lookup table (LU)
> 4.  Rename the temp table (LUTemp) to the original lookup table name (LU)
> 5.  Use the structure list to fix/add any keys, indexes, and/or autonumber
> columns, etc.
> 6.  Delete all fields in the form with popups referring to the lookup
table
> (LU)
> 7.  Re-create all the fields and popups.
>
> Hopefully someone can find a better solution....
>
> Hope that helps,
> Michael
>
> Michael Moser
> EXAQ Micro Services
> www.exaq.com
> Phone: 916-966-8313
> Fax: 916-244-0582
>
>  >>  Hey Folks...
>
>  >>  I've been asking questions over on the "other" R:Base list, and John
> tells
>  >>  me this is probably the better forum...
>
>  >>  I'm trying to convert our office from 6.5++ to 7.1 (build 80), and
I'm
>  >>  finding some issues.  If anyone has any experience with these, and
> could
>  >>  give me an insight, I would appreciate it!
>
>  >>  1) On a multi-table form, I find that my constraints (on the master
> table)
>  >>  are firing as soon as I enter the form.  In other words, as soon as
the
>  >>  blank form opens I get a message saying "Field X cannot be null".
>  >>  Someone on the other list said that they found that converted forms
in
>  >>  7.1, which have multiple tables, try to jump to the second table as
> soon
>  >>  as they are open, and the only way he could prevent it from doing
that
>  >>  was to recreate the form from scratch!
>
>  >>  Has anyone had this experience?  I have a ton of forms like this, and
>  >>  recreating them all from scratch would be a real problem...
>
>  >>  (Possibly related: I find that a blank row appears in the scrolling
> region
>  >>  of the form (table 2) when I open it, even though I haven't added any
>  >>  rows to that second table yet...)
>
>  >>  2) For some reason my "start.cmd" doesn't automatically launch when I
> run
>  >>  7.1.  Instead, it just opens up to the R> window and then stops.  But
>  >>  (weirdly), if I type "run" in the R> Prompt, it tells me "the syntax
is
>  >>  incorrect for the command", and THEN it runs the start.cmd.
>
>  >>  I show the proper start command listed in RBENGINE.CFG properly, I
> think.
>  >>  I only have one copy, and it is the RBTI/RB7 directory...
>
>  >>  3) Am I correct that the R> window and the application are now
separate
>  >>  instances of the database?  I can be logged in to the application,
but
> in
>  >>  the R> window, it tells me "no database connected".  So in order to
> work
>  >>  both in the application and the R> window, you'll need to log in to
> each
>  >>  with you user name and password separately?
>
>  >>  I'm an R:Base programmer about one week every couple years, so I have
a
>  >>  tendency to forget some of this stuff...  {:{)}  Thanks for any
insight
>  >>  anyone may have!
>
>  >>  --Wess Jolley
>  >>  Dartmouth College
>
>

Reply via email to