Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
KMoverObj
Message
From
21/06/2000 13:16:40
Gerald McKinsey
Keystone Consulting Services, Inc.
Yorktown, Indiana, United States
 
General information
Forum:
Visual FoxPro
Category:
The Mere Mortals Framework
Title:
Miscellaneous
Thread ID:
00382030
Message ID:
00382798
Views:
22
Cathi & Roxanne:

---The copying of the code, as described in the manual, to add my own business object is the only way I have used the MoverObj. I always change the SelListObj with one of the application's Business Objects to enforce the Business Rules like you mentioned---

Thanks for reinforcing my concern, and tipping me towards the right path. I'd like to share with you 2 what I've done, and perhaps it may help you. (We've actually used this kind of trick with almost all of Kevin's components that require you to put code snippets in multiple methods. As a result, whenever we drop an BizObj and a cListObjEdit grid on the form, we never have to add any code to make the 2 see each other)

The MoverObj is much simpler, so I'll begin:

(Keystone is our company name, so all subclasses start with "Key"

0. We subclassed KBizObj and named it KeyBizObj
1. Subclass KMoverObj and named it KeyMover
2. Disable his SelListObj as mentioned in his book.
3. Place our own business object (KeyBizObj) on the form. For example I'll put my CustomerObj on there.
4. Now it's time to add his code to the 6 methods. However, instead of doing this in CustomerObj, let's do it at the base parent KeyBizObj level. Now usually you don't want to do this, because it would affect ALL KeyBizObj's throughout the application!
5. However let's make a new property called lKeyMoverObj. It's a logical property and default to FALSE.
6. We already have a subclass of the builder for BizObj, so we'll add a checkbox to this builder that lets us easily change lKeyMoverObj property to TRUE when it's going to be a MoverObj. (i.e.: I drop CustomerObj on a KeyMover to replace his SelListObj, and right click on CustomerObj, hit builder, and click ON for lKeyMoverObj property)

7. Back to the code placed at the parent level KeyBizObj (as I started to say up at #4). In his book, we have to add code to PostInitHook() :
This.Parent.RegisterSelListObj(This)

Change to:
If This.lKeyMoverObj = .T.
_ This.Parent.RegisterSelListObj(This)
EndIf
DODEFAULT()


8. Do that to all the code snippets, and we're done. We now have a KeyMover that only needs 2 steps... Drop business object onto KeyMove, and right click to get builder to check ON the correct property.

I'm curious as to what everone thinks.
If anyone is interested in the other ideas this works for, let me know. For instance, we no longer have to mess with AddViewParameters anymore in bizobj's, or have to write code to make BizObj's point to Graphs or Combobox's, and vica versa.

Dustin.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform