Save/Restore and object??? 
Author Message
 Save/Restore and object???

I have an scx form and want to remove a few objects off it, then later
restore them.  (for what I'm doing the visible property won't work).
Anyway, my problem is that I can save the object like this...

loObjectName = ThisForm.cboPlans
oapp.otoolbar.autorequery.vv_object_sweeper[1,2] = loObjectName

Then remove the object like this....

ThisForm.RemoveObject("cboPlans")

This is the point where I have a problem.  Once I've issued the
RemoveObject, the spot in the array where I was saving it is also gone!
GONE!  arrrrhh!  What the heck is it saving by reference or something?  The
idea was that then I could do this....

loObjectName = oapp.otoolbar.autorequery.vv_object_sweeper[1,2]
ThisForm.AddObject(loObjectName)

..But obviously this isnt going to work if the spot in the array is
destroyed.  The only other thing I can think of is to write a program that
saves all the properties of the object and then cycles though all of that in
some massive array to restore the stupid thing.  Needless to say not only
does that sound like a major pain in the neck, but it'd probably take quite
a while to run.....



Fri, 10 Dec 2004 22:29:02 GMT  
 Save/Restore and object???
Victor,

Why won't the Visible property work ? Are you cycling through the objects ?

Suggest you leave the object.  If the user mustn't see it set the visible to
false

Use the Enabled/Comment/tag property (or add one of your own)  for deciding
what to do with it

for i = ...
    obj = ....
   if( !obj.Enabled )
        loop
   endif

  && do the stuff you have to do

endfor

Gregory
__________

| I have an scx form and want to remove a few objects off it, then later
| restore them.  (for what I'm doing the visible property won't work).
| Anyway, my problem is that I can save the object like this...
|
| loObjectName = ThisForm.cboPlans
| oapp.otoolbar.autorequery.vv_object_sweeper[1,2] = loObjectName
|
| Then remove the object like this....
|
| ThisForm.RemoveObject("cboPlans")
|
|
| This is the point where I have a problem.  Once I've issued the
| RemoveObject, the spot in the array where I was saving it is also gone!
| GONE!  arrrrhh!  What the heck is it saving by reference or something?
The
| idea was that then I could do this....
|
| loObjectName = oapp.otoolbar.autorequery.vv_object_sweeper[1,2]
| ThisForm.AddObject(loObjectName)
|
| ..But obviously this isnt going to work if the spot in the array is
| destroyed.  The only other thing I can think of is to write a program that
| saves all the properties of the object and then cycles though all of that
in
| some massive array to restore the stupid thing.  Needless to say not only
| does that sound like a major pain in the neck, but it'd probably take
quite
| a while to run.....
|
|
|



Fri, 10 Dec 2004 22:49:57 GMT  
 Save/Restore and object???
Quote:
> Why won't the Visible property work ? Are you cycling through the objects

?

Quote:
> Suggest you leave the object.  If the user mustn't see it set the visible
to
> false

I was afraid someone was going to ask me that...and I'll try to answer as
breifly as possible.

The app is using stricly remote views.  The situation is that UserA enters
data and UserB can't see it yet.  The application, as I found it, has no
'global requery' mechnisim.
So...some of the comboboxes and grids' recordsources happend to be
non-parameterized remote views.  My solution, for the moment at least, is to
have a timer that the user can adjust, and like every 60 seconds or so it
will requery the non-parameterized remote views.  The PROBLEM, much to my
disapointment, is that when you requery a view that's the recordsource or
rowsource for a grid or combobox, it breaks the grid and/or
combobox....reason being that for that nano-second that VFP is acutally
doing the requery, the view doesn't exist at all...thus causing the
grid/comboboxes to break.

Anway, with all this in mind, you can see that just making them invisible is
defeating my purpose.  The only other thing I can think of is to cycle
though each of the objects on the screen(s), determine if it's a combobox or
gird, then save all the data-properties somewhere, requery the views, then
put the data-properties back.  Again it just seems a whole lot eaiser to be
able to save the stupid object somewhere, remove it, then requery, then plop
the sucker back on the screen.  It's like 2 lines of code as opposed to a
mile of it...



Fri, 10 Dec 2004 23:03:16 GMT  
 Save/Restore and object???
Victor,

I have a grid with a view as RecordSource

the requery() does not break the grid at all

are you changing/setting/resetting  the grid's recordsource before/after the
requery ??

____________-

| > Why won't the Visible property work ? Are you cycling through the
objects
| ?
|
| > Suggest you leave the object.  If the user mustn't see it set the
visible
| to
| > false
|
| I was afraid someone was going to ask me that...and I'll try to answer as
| breifly as possible.
|
| The app is using stricly remote views.  The situation is that UserA enters
| data and UserB can't see it yet.  The application, as I found it, has no
| 'global requery' mechnisim.
| So...some of the comboboxes and grids' recordsources happend to be
| non-parameterized remote views.  My solution, for the moment at least, is
to
| have a timer that the user can adjust, and like every 60 seconds or so it
| will requery the non-parameterized remote views.  The PROBLEM, much to my
| disapointment, is that when you requery a view that's the recordsource or
| rowsource for a grid or combobox, it breaks the grid and/or
| combobox....reason being that for that nano-second that VFP is acutally
| doing the requery, the view doesn't exist at all...thus causing the
| grid/comboboxes to break.
|
| Anway, with all this in mind, you can see that just making them invisible
is
| defeating my purpose.  The only other thing I can think of is to cycle
| though each of the objects on the screen(s), determine if it's a combobox
or
| gird, then save all the data-properties somewhere, requery the views, then
| put the data-properties back.  Again it just seems a whole lot eaiser to
be
| able to save the stupid object somewhere, remove it, then requery, then
plop
| the sucker back on the screen.  It's like 2 lines of code as opposed to a
| mile of it...
|
|
|



Fri, 10 Dec 2004 23:34:42 GMT  
 Save/Restore and object???

Quote:
> I have a grid with a view as RecordSource
> the requery() does not break the grid at all

Interesting, because I've had the problem for years along with everyone else
I've talked to.

Quote:
> are you changing/setting/resetting  the grid's recordsource before/after
the
> requery ??

No I'm not...but that has been my workaround for years...
remove the recordsource....
do the requery....
put the recordsource back...

This is a well known foxpro issue I don't see how you can't be having the
same problem.



Fri, 10 Dec 2004 23:36:48 GMT  
 Save/Restore and object???
Ok, I'm no expert here but I'd like to add my observations.

What I do for grids is this:
First is I lock the screen to reduce annoying flicker.
Then I set the grid's recordsource property to a blank string.  For example:
thisform.grid1.recordsource=''.  (That's two single quotes.)
Then I requery the source table.
Then I set the grid's recordsource back where it belongs.
Then unlock the screen.

Works fine for me with grids but I've never tried it with comboboxes or
lists.  I would suspect that it would behave similarly though.  And with
this solution you could use the visible property instead of deleting/adding.

Another possible solution, if you really want to delete and readd objects,
would be to make classes of the objects with properties set the way you'd
like.  Then you could add your objects back using those classes and I think
they'd retain the properties and any custom methods as well.

Just seems to me that using the visible property is much simpler than
deleting and readding objects to a form programmatically.

Linn


Quote:
> I was afraid someone was going to ask me that...and I'll try to answer as
> breifly as possible.

> The app is using stricly remote views.  The situation is that UserA enters
> data and UserB can't see it yet.  The application, as I found it, has no
> 'global requery' mechnisim.
> So...some of the comboboxes and grids' recordsources happend to be
> non-parameterized remote views.  My solution, for the moment at least, is
to
> have a timer that the user can adjust, and like every 60 seconds or so it
> will requery the non-parameterized remote views.  The PROBLEM, much to my
> disapointment, is that when you requery a view that's the recordsource or
> rowsource for a grid or combobox, it breaks the grid and/or
> combobox....reason being that for that nano-second that VFP is acutally
> doing the requery, the view doesn't exist at all...thus causing the
> grid/comboboxes to break.

> Anway, with all this in mind, you can see that just making them invisible
is
> defeating my purpose.  The only other thing I can think of is to cycle
> though each of the objects on the screen(s), determine if it's a combobox
or
> gird, then save all the data-properties somewhere, requery the views, then
> put the data-properties back.  Again it just seems a whole lot eaiser to
be
> able to save the stupid object somewhere, remove it, then requery, then
plop
> the sucker back on the screen.  It's like 2 lines of code as opposed to a
> mile of it...



Fri, 10 Dec 2004 23:34:51 GMT  
 Save/Restore and object???
Yes this is the same logic I use for the grids, but I want to do this
dynamicly for all the grids & comboboxes on the screen, and I want to write
it once to work on all my screens.

And as for making them invisible...that won't work because their still tied
to the datasources.

This brings me back to my original idea...cant you just SAVE an
object...REMOVE and object, then ADD the object you saved?  It should be
like 3 lines of code!!  It's like no matter how else I do this it's going to
be a hassle...arrrrrHHH!


Quote:
> Ok, I'm no expert here but I'd like to add my observations.

> What I do for grids is this:
> First is I lock the screen to reduce annoying flicker.
> Then I set the grid's recordsource property to a blank string.  For
example:
> thisform.grid1.recordsource=''.  (That's two single quotes.)
> Then I requery the source table.
> Then I set the grid's recordsource back where it belongs.
> Then unlock the screen.

> Works fine for me with grids but I've never tried it with comboboxes or
> lists.  I would suspect that it would behave similarly though.  And with
> this solution you could use the visible property instead of
deleting/adding.

> Another possible solution, if you really want to delete and readd objects,
> would be to make classes of the objects with properties set the way you'd
> like.  Then you could add your objects back using those classes and I
think
> they'd retain the properties and any custom methods as well.

> Just seems to me that using the visible property is much simpler than
> deleting and readding objects to a form programmatically.

> Linn



> > I was afraid someone was going to ask me that...and I'll try to answer
as
> > breifly as possible.

> > The app is using stricly remote views.  The situation is that UserA
enters
> > data and UserB can't see it yet.  The application, as I found it, has no
> > 'global requery' mechnisim.
> > So...some of the comboboxes and grids' recordsources happend to be
> > non-parameterized remote views.  My solution, for the moment at least,
is
> to
> > have a timer that the user can adjust, and like every 60 seconds or so
it
> > will requery the non-parameterized remote views.  The PROBLEM, much to
my
> > disapointment, is that when you requery a view that's the recordsource
or
> > rowsource for a grid or combobox, it breaks the grid and/or
> > combobox....reason being that for that nano-second that VFP is acutally
> > doing the requery, the view doesn't exist at all...thus causing the
> > grid/comboboxes to break.

> > Anway, with all this in mind, you can see that just making them
invisible
> is
> > defeating my purpose.  The only other thing I can think of is to cycle
> > though each of the objects on the screen(s), determine if it's a
combobox
> or
> > gird, then save all the data-properties somewhere, requery the views,
then
> > put the data-properties back.  Again it just seems a whole lot eaiser to
> be
> > able to save the stupid object somewhere, remove it, then requery, then
> plop
> > the sucker back on the screen.  It's like 2 lines of code as opposed to
a
> > mile of it...



Fri, 10 Dec 2004 23:46:08 GMT  
 Save/Restore and object???

Quote:
> This is a well known foxpro issue I don't see how you can't be having the
> same problem.

The problem appear with many commands (pack, zap etc) or if you manually
close/open the workarea. But REQUERY() changes athe workarea in a way that
VFP's grid don't notice and they don't break.


Fri, 10 Dec 2004 23:46:20 GMT  
 Save/Restore and object???
Victor,

I'll go along with what Remus says

just do the requery. Do not touch the recordsource.  You're grid will stay
intact

**** do not ***| remove the recordsource....
| do the requery....
**** do not *** | put the recordsource back

______________________________

| > I have a grid with a view as RecordSource
| > the requery() does not break the grid at all
|
| Interesting, because I've had the problem for years along with everyone
else
| I've talked to.
|
| > are you changing/setting/resetting  the grid's recordsource before/after
| the
| > requery ??
|
| No I'm not...but that has been my workaround for years...
| remove the recordsource....
| do the requery....
| put the recordsource back...
|
| This is a well known foxpro issue I don't see how you can't be having the
| same problem.
|
|
|



Sat, 11 Dec 2004 00:06:38 GMT  
 Save/Restore and object???
Well if that was possible then I wouldn't have this problem to begin with.
The way these guys designed the app, everything (and I mean everything) runs
in the default datasession.  Perhaps this is one of the things that is
preventing me from doing the requery, or maybe it's that these particular
views dont have any parameters....in any event it doesnt matter this is not
my real quest here.....

Remember when I said "I was afraid someone would ask me that".....now you
see why, eh? hahaha

Soooo...back to my original question:
On a form, I want to save, remove, then restore an object !!!!  Does anyone
know how to do this?


Quote:
> Victor,

> I'll go along with what Remus says

> just do the requery. Do not touch the recordsource.  You're grid will stay
> intact

> **** do not ***| remove the recordsource....
> | do the requery....
> **** do not *** | put the recordsource back

> ______________________________


> | > I have a grid with a view as RecordSource
> | > the requery() does not break the grid at all
> |
> | Interesting, because I've had the problem for years along with everyone
> else
> | I've talked to.
> |
> | > are you changing/setting/resetting  the grid's recordsource
before/after
> | the
> | > requery ??
> |
> | No I'm not...but that has been my workaround for years...
> | remove the recordsource....
> | do the requery....
> | put the recordsource back...
> |
> | This is a well known foxpro issue I don't see how you can't be having
the
> | same problem.
> |
> |
> |



Sat, 11 Dec 2004 00:37:35 GMT  
 Save/Restore and object???
Victor,

Why go through all that trouble ?

have you tried doing a simple requery() without touching the recordsource ?
And does that solve  the problem ?

Now, as to the object magic.  It ain't easy.  You have to 'capture/save' all
the properties (grid is a couple of levels down) of the object and destroy
it.

To restore, recreate the object (add to the form in this case) and restore
all the properties you saved.  However, this won't work for edited methods
as far as I know.  In addition, you are back to square one, since you'll
have to set the RecordSource of the newly created/added grid ;-)

Best of luck

Gregory
____________________


| Well if that was possible then I wouldn't have this problem to begin with.
| The way these guys designed the app, everything (and I mean everything)
runs
| in the default datasession.  Perhaps this is one of the things that is
| preventing me from doing the requery, or maybe it's that these particular
| views dont have any parameters....in any event it doesnt matter this is
not
| my real quest here.....
|
| Remember when I said "I was afraid someone would ask me that".....now you
| see why, eh? hahaha
|
| Soooo...back to my original question:
| On a form, I want to save, remove, then restore an object !!!!  Does
anyone
| know how to do this?
|
|


| > Victor,
| >
| > I'll go along with what Remus says
| >
| > just do the requery. Do not touch the recordsource.  You're grid will
stay
| > intact
| >
| >
| > **** do not ***| remove the recordsource....
| > | do the requery....
| > **** do not *** | put the recordsource back
| >
| > ______________________________


| > | > I have a grid with a view as RecordSource
| > | > the requery() does not break the grid at all
| > |
| > | Interesting, because I've had the problem for years along with
everyone
| > else
| > | I've talked to.
| > |
| > | > are you changing/setting/resetting  the grid's recordsource
| before/after
| > | the
| > | > requery ??
| > |
| > | No I'm not...but that has been my workaround for years...
| > | remove the recordsource....
| > | do the requery....
| > | put the recordsource back...
| > |
| > | This is a well known foxpro issue I don't see how you can't be having
| the
| > | same problem.
| > |
| > |
| > |
| >
| >
|
|



Sat, 11 Dec 2004 01:26:15 GMT  
 Save/Restore and object???
Quote:
> Why go through all that trouble ?

Because if I could SAVE the whole object, then I don't have to store all the
properties for it.

Quote:
> have you tried doing a simple requery() without touching the recordsource

?
Yes

Quote:
> And does that solve  the problem ?

Not 100% of the time.

Quote:
> Now, as to the object magic.  It ain't easy.  You have to 'capture/save'
all
> the properties (grid is a couple of levels down) of the object and destroy
> it.

Yeah this is what I was trying to avoid doing..just seems like a hell of a
lot eaiser if I had the whole object to start with! hahaha

Quote:
> To restore, recreate the object (add to the form in this case) and restore
> all the properties you saved.  However, this won't work for edited methods
> as far as I know.  In addition, you are back to square one, since you'll
> have to set the RecordSource of the newly created/added grid ;-)

Yepper...like a said not overly complicated at all...just a major pain in
the neck.

Wish I could just say ThisForm.AddObject("mySavedObject") and be done with
it....but I've been getting some help on the UT and I guess you just can't
do this with objects...just as I was afraid saves by reference only....

I've got another plan in my head on how to handle the problem...I'll give it
a shot.....arrrrh!



Sat, 11 Dec 2004 01:49:33 GMT  
 Save/Restore and object???
Victor,
Ultimately an object that normally lives in a container can't "stand alone",
so you can't save it. You might be able to move it to another container, but
I haven't tried this in code.

Rick


Quote:
> I have an scx form and want to remove a few objects off it, then later
> restore them.  (for what I'm doing the visible property won't work).
> Anyway, my problem is that I can save the object like this...

> loObjectName = ThisForm.cboPlans
> oapp.otoolbar.autorequery.vv_object_sweeper[1,2] = loObjectName

> Then remove the object like this....

> ThisForm.RemoveObject("cboPlans")

> This is the point where I have a problem.  Once I've issued the
> RemoveObject, the spot in the array where I was saving it is also gone!
> GONE!  arrrrhh!  What the heck is it saving by reference or something?
The
> idea was that then I could do this....

> loObjectName = oapp.otoolbar.autorequery.vv_object_sweeper[1,2]
> ThisForm.AddObject(loObjectName)

> ..But obviously this isnt going to work if the spot in the array is
> destroyed.  The only other thing I can think of is to write a program that
> saves all the properties of the object and then cycles though all of that
in
> some massive array to restore the stupid thing.  Needless to say not only
> does that sound like a major pain in the neck, but it'd probably take
quite
> a while to run.....



Sat, 11 Dec 2004 02:48:44 GMT  
 Save/Restore and object???
Interesting idea...and I thought of that before.  Problem is that there's no
real way to 'move' it to another container, and the 'addobject' method, if
run outside the existing container, needs the classname and class to work
properly.  unfortunately this app I'm working on isn't designed quite good
enough to let me to all that.


Quote:
> Victor,
> Ultimately an object that normally lives in a container can't "stand
alone",
> so you can't save it. You might be able to move it to another container,
but
> I haven't tried this in code.

> Rick



> > I have an scx form and want to remove a few objects off it, then later
> > restore them.  (for what I'm doing the visible property won't work).
> > Anyway, my problem is that I can save the object like this...

> > loObjectName = ThisForm.cboPlans
> > oapp.otoolbar.autorequery.vv_object_sweeper[1,2] = loObjectName

> > Then remove the object like this....

> > ThisForm.RemoveObject("cboPlans")

> > This is the point where I have a problem.  Once I've issued the
> > RemoveObject, the spot in the array where I was saving it is also gone!
> > GONE!  arrrrhh!  What the heck is it saving by reference or something?
> The
> > idea was that then I could do this....

> > loObjectName = oapp.otoolbar.autorequery.vv_object_sweeper[1,2]
> > ThisForm.AddObject(loObjectName)

> > ..But obviously this isnt going to work if the spot in the array is
> > destroyed.  The only other thing I can think of is to write a program
that
> > saves all the properties of the object and then cycles though all of
that
> in
> > some massive array to restore the stupid thing.  Needless to say not
only
> > does that sound like a major pain in the neck, but it'd probably take
> quite
> > a while to run.....



Sat, 11 Dec 2004 03:35:14 GMT  
 Save/Restore and object???
Victor,

Jim's answer on the UT finally convinced you then ?


| > Why go through all that trouble ?
| Because if I could SAVE the whole object, then I don't have to store all
the
| properties for it.
|
| > have you tried doing a simple requery() without touching the
recordsource
| ?
| Yes
|
| > And does that solve  the problem ?
| Not 100% of the time.
|
| > Now, as to the object magic.  It ain't easy.  You have to 'capture/save'
| all
| > the properties (grid is a couple of levels down) of the object and
destroy
| > it.
| Yeah this is what I was trying to avoid doing..just seems like a hell of a
| lot eaiser if I had the whole object to start with! hahaha
|
| > To restore, recreate the object (add to the form in this case) and
restore
| > all the properties you saved.  However, this won't work for edited
methods
| > as far as I know.  In addition, you are back to square one, since you'll
| > have to set the RecordSource of the newly created/added grid ;-)
|
| Yepper...like a said not overly complicated at all...just a major pain in
| the neck.
|
| Wish I could just say ThisForm.AddObject("mySavedObject") and be done with
| it....but I've been getting some help on the UT and I guess you just can't
| do this with objects...just as I was afraid saves by reference only....
|
| I've got another plan in my head on how to handle the problem...I'll give
it
| a shot.....arrrrh!
|
|



Sat, 11 Dec 2004 14:51:04 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. How to save and restore table layout?

2. Need to save/restore FoxPro environment.

3. SAVE WINDOWS, RESTORE WINDOWS commands

4. Save and restore properties

5. Saving and restoring printed reports ?

6. How to save/restore screen color?

7. Save and Restore REPROCESS setting

8. Help: Strict Date and save/restore filters

9. Restoring objects / read / FPW

10. How to save all object from form ?

11. The Value of current object is not save to database

12. Save Object in a record

 

 
Powered by phpBB® Forum Software