I am currently reading "Build Your Own Framework with Visual
FoxPro" by Kenneth Chazotte and published by Hentzenwerke Publishing.

Chapter 7 is a bit of a bear. I have not worked with
datasessions before. I thought I was following the text reasonably
well, but I do not understand the code on page 94 (the last page of
the chpater).

Part of the problem is that 1) the class code is spattered
throughout the chapter and does not appear to be complete, and 2) I
get errors trying to run various pieces of code. I am using VFP 6
(for which I understand getting errors) and the VFP 9 beta (for which
I do not understand getting errors). The error I get is that a DLL is
missing.

1) What exactly is being created by the two createobject() calls?

2) What does
set datasession to this.osession.datasessionid
do ***in terms of the framework***?

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Gene Wirchenko <genew (AT) mail (DOT) ocis.net> wrote:
At the risk of spawning a debate on the merits (or otherwise) of
frameworks, the problem with most of the reading matter on this
subject is that the authors go hog-wild with their own way of doing
things.

Here's my 2 cents. Frameworks are for dummies!
A tad harsh?
Well how about this ... Frameworks are for lazy dummies!!

Frameworks are for people who like the "one size fits all"
principle. It's RAD at the expense of ... er ... customer
requirements and creativity.

Wait a minute! As a close observer of the NG and someone who has
an elephantine memory for trivia, didn't you say "bye-bye" to FoxPro
a while back because you were moving to WinDev?
If I'm correct, how did the WinDev experience go?
I had a look at WinDev a couple of months ago and came to the
conclusion that it's a pathetic attempt to make developing
Windows applications relatively simple for non-programmers.
After a day of the WinDev "experience, I uninstalled it.

If you're trying to emulate the WinDev paradigm via a VFP
framework, my advice is ... don't waste your time.

Instead, spend time creating your specialised subclasses
as and when they're required for your current project.

[snipped rest]

-Roger
--
Roger Ansell
Australian President
FE AVP et Cie
Adelaide, Australia

My real email address is ransell at senet dot com dot au

"Roger Ansell" <notmyreal (AT) emailaddress (DOT) com> wrote:

A well-designed, appropriately-used framework can save
considerable effort reinventing the wheel.

Not me. (Sorry, but the elephant seems to have sat on you. What
*is* WinDev?)

[snip]

That is a lot of the work of a framwork.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

A bit of subject but I agree with you on frameworks Gene. I decided to use
the Promatrix framework vpm 4 years ago and have not regretted the decision.
It does all the spadework, throws in hundreds of useful features
automatically like security, menu permissions etc etc and yet leaves you the
freedom to develop as you want. Link it up with xCase and xCase2vpm and the
time saved is immeasurable.

I remember when FPW2.6 came out a similar discussion took place - real
programmers would program the spr files direct - dummies like me would use
the infinitely faster and simpler screen designers.

Sincerely

Stephen

"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote

Hello Gene;

I couldn't agree more with Roger. 3rd party Frameworks are a rip-off and are
only great when you are writing a simple app like an address book etc. They
are the toughest things to customize to what you are doing... as now you
have to learn the authors style of programming and have to be extremely
familiar with the code behind the framework as changing something may
adversely effect something else down the line.

Regarding datasessions, they are relatively easy to use. The simplest way
(we use this method) is create your master form as "2 Private Datasession".
Make any child forms that you will run from the master into "1 Default Data
session", to be on the safe side send the Master form (so you manipulate it
from the child) and the Master's DatasessionID as parameters to the child.
This doubly ensures that the child becomes part of the Masters datasession.

I am sure some one else here has a different approach to achieve the same
result... that is my argument against frameworks.

Good Luck
Mohammed
www.imaginecorp.com/whatwedo.htm


"Gene Wirchenko" <genew (AT) mail (DOT) ocis.net> wrote


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 9/28/2004

Stephen & Shelagh Ibbs wrote:
On top of that. The really leverage the product and be productive, you
either have to use an off the shelf framework, or roll your own. Where
I work we rolled our own to give us the functionality that we wanted.

--
Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com

Hello Gene,

I just stumbled across this message. Unfortunately, this is a site I do
not frequent and therefore was unaware of the difficulties you were having
with Chapter 7.

The CREATEOBJECT call creates a data environment class. The name of an
environment class is passed in as a parameter to set up the
environment(SET TALK, SET EXCLUSIVE...etc.)

When an object is created, it is bound (operates within) the session in
which it was created. Session objects are no different. Furhter, when a
session object is created, the current data session is not changed. For
example, if you type the following in the command window:
*--Open the data session window
SET VIEW ON
*--Create a session object
oDS = CREATEOBJECT("Session")

You will see that the Current Session is still 1 (Default)

To access the newly created data session, you need to manually select the
new data session. Continuing with the example, type the following in the
command window:

*--Change the DataSession
SET DATASESSION TO oDS.DataSessionId
and you will see that the Current Session is changed to Session(2).

The same logic applies in the framework. The framework is not interested
in accessing the environment in which the object was created so we (I)
manually switch to the newly created session as follows:

SET DATASESSION TO This.oSession.DataSessionId

Regards,
Ken.