Was this the same logic and method that was used to remove the option of allowing the user to modify a lookup field in a form? I agree that using the new getproperty features, I have been able to work around the change, but I don't see why that feature needed to be deleted. It seemed to be a pretty logical and intuitive option for fields.
Mike
-------------- Original message from Dennis McGrath <[EMAIL PROTECTED]>: --------------
> Hi Mike,
>
> Thanks for your comments.
>
> I do think my last email spelled out my concerns in a logical manner.
> I know if Razzak finds the arguments reasonable, he will do something about
> them. I've been very impressed with the responsiveness of Razzak and the dream
> team as of late.
>
> I probably wouldn't have made much of a fuss except the very first form I tried
> to convert required some arcane knowledge to fix it.
>
> I understand having to tweak visual attributes after a conversion, but
> functional failures are a little harder to accept.
>
> I'm sure that overall I will be impressed with the product in its current state.
>
> All the best,
> Dennis
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of MikeB
> Sent: Friday, May 30, 2008 5:25 PM
> To: RBASE-L Mailing List
> Subject: [RBASE-L] - Re: conversion anomoly
>
> Dennis,
>
> Sorry I'm jumping in a little late, but I have been slaving for myself all day
> (hate when that happens!).
>
> I think some perspective on how we have arrived at ver 7.6 might be helpful.
>
> Even though you might find issues that seem a little quirky or illogical at the
> moment, you should know that most everything about RBase 7.6 / 8.0, is the
> result of input from your peer group.
>
> You have been here long enough to know that the way things are displayed or
> dialoged, is through discussion in this forum usually, but not always, arriving
> at consensus on subject matter, and just like Magic, within days (and sometimes
> hours), how and what was described appears in the product.
>
> Admittedly, sometimes it seems to be at odds with how everyone else does it,
> but by and large, most things are as expected.
>
> But the big picture is we have (collectively) advanced the product to a state
> that still elicits "oohs" and "aahs" from long time developers that thought the
> product was awful damn good at the 7.5 stage.
>
> And to add further to that, I will bet that as long as Razzak remains above
> ground, you can expect the product to continue to improve so long as the
> faithful pursue it towards perfection.
>
> There isn't anything you are going to go through in the conversion process that
> the dozens of able and selfless people here like Dawn, Bill, Emmitt, Claudine,
> Javier, Adrian, Gunnar, Steve, James, La rry, and many more, have not already
> done before.
>
> Their individual experiences through trials by fire are at the ready to help
> you any time you need it in the very same way you would do for anyone else.
>
> Mike
>
> > Thanks, Dawn,
> >
> > That helps a little.
> >
> > In that case I would expect with a one-to-many property set, my third table
> > would never show any data since it had no linking column to the first table!
> > Instead, it pulled all the rows in the third table. Obviously, more light
> > needs to be shed on this property!
> >
> > And, the many-to-many should be the default option, since it is the one most
> > likely to be used.
> >
> > Dennis McGrath
> >
> >
> >
> > ----------
> > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
> > [EMAIL PROTECTED]
> > Sent: Friday, May 30, 2008 12:49 PM
> > To: RBASE-L Mailing List
> > Subject: [RBASE-L] - Re: conversion anomoly
> >
> >
> > Ya - that's one of those things that's not instinctive, since it differs from
> > the standard definition fo one to many and many to many.
> >
> > Basically, it's TABLES instead of RECORDS: With one to many, it means I can
> > link one table to many tables. With "many to many", it means I can have many
> > tables linking to many tables.
> >
> > I'm sure that's not the "definition", but that's how I learned to remember to
> > check that box!
> >
> >
> > Dawn Hast
> >
> >
> >
> > Dennis McGrath <[EMAIL PROTECTED]>wrote on 05/30/2008 01:09:52 PM:
> >
> > > Dawn,
> > > ;
> > > That was it!
> > >
> > > LOL! I check the help and it is not much help.
> > >
> > > What exactly does the "one to many" option do? The result
> > > definitely does not look logical to me in any way.
> > > The help does not tell me anything useful!
> > >
> > > Thanks
> > > Dennis
> > >
> > >
> > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of
> > > [EMAIL PROTECTED]
> > > Sent: Friday, May 30, 2008 11:44 AM
> > > To: RBASE-L Mailing List
> > > Subject: [RBASE-L] - Re: conversion anomoly
> > >
> > >
> > > Dennis,
> > >
> > > Make sure you have "Many to Many" checked under Form Properties >
> > > Table Relations.
> > >
> > > Dawn Hast
> > >
> > >
> > >
> > > Dennis McGrath <[EMAIL PROTECTED]>wrote on 05/30/2008 12:40:20 PM:
> > >
> > > > I'm doing my first conversion from RBDOS 7.5 to RBWIN 7.6
> > > >
> > > > I have a 3 table form with 3 regions
> > > >
> > > > RBWIN 6.5++ (latest version 1.866) converted the dos form fine. I
> > > > tweaked the scrolling regions a bit and the form works great.
> > > >
> > > > I converted that form to 7.6 (latest version 3.30516)
> > > >
> > > > The third scrolling region does not link up correctly, it shows all
> > > > the records in the third table, not just the records that link to table 2
> > > >
> > > > Any way I can fix this short of removing the region and table and
> > > > adding it back manually?
> > > > I sure don't want to do this for all my 3+ forms!!!
> > > >
> > > > Finally trying to catch up!
> > > > Dennis McGrath
> > > >
> > > >
> >
> >
> >
>
>
