_app object question

[Frank J. Polan]

There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects

Public variables - no problem - never used them even in the DOS
version

I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used

-------------- original question <snipped> ---------------

Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings

In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------

The above values are checked as required when opening a menu item or
form

Thanks

Frank Polan

[Greg Neid]

Hi Frank,

I have used the _app. object quite successfully to hold data that is required in many modules. I also instantiate special purpose objects and store overall data pieces in created properties at the start up of a web app. These properties are used throughout the various programs. These are web apps where there are sometimes a dozen or so concurrent instances of the program. It all works well.

I rarely use public variables, but I know of no reason why they should fail. I have a few instances of public variables, but I don't like them because I like variables to be local to a function. It saves a potential problem in cross-naming variables.

Greg

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------
The above values are checked as required when opening a menu item or
form
Thanks
Frank Polan

[Frank J. Polan]

Greg,

My experience has been exactly like yours . That's why I'm surprised
that some people on the NG recommend not using the _app object.
I'd like to know their reasoning

Thanks for the confirmation

Frank Polan

Post by Greg Neid
Hi Frank,
I have used the _app. object quite successfully to hold data that is required in many modules. I also instantiate special purpose objects and store overall data pieces in created properties at the start up of a web app. These properties are used throughout the various programs. These are web apps where there are sometimes a dozen or so concurrent instances of the program. It all works well.
I rarely use public variables, but I know of no reason why they should fail. I have a few instances of public variables, but I don't like them because I like variables to be local to a function. It saves a potential problem in cross-naming variables.
Greg

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------
The above values are checked as required when opening a menu item or
form
Thanks
Frank Polan

[Bruce R. Roland]

Frank

Post by Frank J. Polan
My experience has been exactly like yours . That's why I'm surprised
that some people on the NG recommend not using the _app object.
I'd like to know their reasoning
Thanks for the confirmation

As one of the newbies on the block I took a lot of this to mean that overall the advice was not to not use the _app object but instead to make sure it is not overused or to ensure it is not used for a catchal -l as a place to put things which may be applicable to one part of an application but not to all of the application (i.e., that the _app object is for - or what should be placed in it are - things which are globally used by an application and not things which are - say - form or sub program specific.

The problem here for the nebies like me is that - because our understanding is low right now - some of the discussion is confusing - first because we don't fully understand what the _app object is or what it does and second - mainly because of the first reason - it makes us scratch our heads and say - ok do we or don't we. Without the understanding = and the confusion over the discussion - and the fact that our programs are currently running as is - it creates a situation where some of us newbies are likely to just keep on doing what we are doing - even if incorrect because we can't sort it out.

I.e., while it may be good to have a discussion in the manner and at the level of this discussion - it is not helping us newbies understand much at this point and so is highly unlikely to help us change to good programming habits. If the experts are in disagreement and they know dbase what do we do?

This post not meant to pinch anyones feelings - it is simply meant to help the pros see a newbie perspective on these discussions.

Bruce

[Greg Hill]

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------

Lets look at the alternative.
My app starts, I prompt the user for login credentials, this requires an
open table and a lookup, so if he successfully logs in, why should I leave
that table open? Why not store it to _app.userid or something? That is what
I do and it works perfectly.
If one does not store it in a system accessible like object or variable,
then he or she would have to resort to leaving that table opened and hope
that the record pointer doesn't get moved and also invite record locking
issues, along with more memory. Also, if the record pointer gets moved it
would cause errors when referencing user attributes. By the way, I use the
userid information in many places throughout the application.

I use the heck out of the _app object and have never ever had one problem
with it. I also use public variable for arrays primarily (now that I might
do differently someday) but not because it causes me issues, only because it
is not as dynamic as building arrays each time a form is opened, which could
also be argued depending on the size of the array.

I have not experienced one reason to "not" use the _app object and actually
same goes for public variables, they work as long as you work them.

Greg Hill

[Frank J. Polan]

Greg

Again, it matches my experience.. So why are new users in the Getting
Started ng being told not to use the _app object?

Thanks for the confirmation

Frank Polan

Post by Greg Hill

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------

Lets look at the alternative.
My app starts, I prompt the user for login credentials, this requires an
open table and a lookup, so if he successfully logs in, why should I leave
that table open? Why not store it to _app.userid or something? That is what
I do and it works perfectly.
If one does not store it in a system accessible like object or variable,
then he or she would have to resort to leaving that table opened and hope
that the record pointer doesn't get moved and also invite record locking
issues, along with more memory. Also, if the record pointer gets moved it
would cause errors when referencing user attributes. By the way, I use the
userid information in many places throughout the application.
I use the heck out of the _app object and have never ever had one problem
with it. I also use public variable for arrays primarily (now that I might
do differently someday) but not because it causes me issues, only because it
is not as dynamic as building arrays each time a form is opened, which could
also be argued depending on the size of the array.
I have not experienced one reason to "not" use the _app object and actually
same goes for public variables, they work as long as you work them.
Greg Hill

[Geoff Wass [dBVIPS]]

Post by Frank J. Polan
Greg
Again, it matches my experience.. So why are new users in the Getting
Started ng being told not to use the _app object?
Thanks for the confirmation
Frank Polan

Frank,

As Bruce has said, it is very easily abused. There is a tendency of
former DOS programmers to just convert all public variables to _app
properties and move on. The problems are not obvious at first.

One of the advantages of OOP is that you have the opportunity to reuse
objects. However, if you start tying your classes to something external
like a public variable, an _app property, a table or whatever, they are
no longer encapsulated and thus hard to reuse (and possibly impossible
to reuse). It makes debugging more difficult and, in the hands of a
novice, debugging can easily become a nightmare. As I said in the other
news group, when you start sub-classing your classes, and perhaps making
sub-classes of the sub-classes, you can easily lose sight of the
external dependencies (ie. _app properties) involved. This can make
testing and debugging more difficult than necessary.

As I have said, I have used _app a lot in the past. It can be done. You
won't die, you won't go blind and your dog won't get worms. If you are
using it successfully then you need not worry. No tragedy will befall
your program. You just need to be aware of the drawbacks.

[Frank J. Polan]

Geoff

On Sat, 29 Nov 2008 01:37:25 -0500, Geoff Wass [dBVIPS]

Post by Geoff Wass [dBVIPS]
As I have said, I have used _app a lot in the past. It can be done. You
won't die, you won't go blind and your dog won't get worms. If you are
using it successfully then you need not worry. No tragedy will befall
your program. You just need to be aware of the drawbacks.

No patronizing please -One way or the other, I've been working with
computers and writing programs for a living probably for more years
than your age<g>

Anyway I've posted a final comment in the getting started ng.

Thanks

Frank Polan

[Geoff Wass [dBVIPS]]

Post by Frank J. Polan
Geoff
On Sat, 29 Nov 2008 01:37:25 -0500, Geoff Wass [dBVIPS]

Post by Geoff Wass [dBVIPS]
As I have said, I have used _app a lot in the past. It can be done. You
won't die, you won't go blind and your dog won't get worms. If you are
using it successfully then you need not worry. No tragedy will befall
your program. You just need to be aware of the drawbacks.

No patronizing please -One way or the other, I've been working with
computers and writing programs for a living probably for more years
than your age<g>
Anyway I've posted a final comment in the getting started ng.
Thanks
Frank Polan

Frank,

I was not trying to patronize. I was trying to lighten things up. My
apologies if you found it offensive.

[Frank J. Polan]

Geoff

I did a <g>

No apologies necessary

Frank Polan



On Sun, 30 Nov 2008 02:22:35 -0500, Geoff Wass [dBVIPS]

Post by Greg Neid

Post by Frank J. Polan
Geoff
On Sat, 29 Nov 2008 01:37:25 -0500, Geoff Wass [dBVIPS]

Post by Geoff Wass [dBVIPS]
As I have said, I have used _app a lot in the past. It can be done. You
won't die, you won't go blind and your dog won't get worms. If you are
using it successfully then you need not worry. No tragedy will befall
your program. You just need to be aware of the drawbacks.

No patronizing please -One way or the other, I've been working with
computers and writing programs for a living probably for more years
than your age<g>
Anyway I've posted a final comment in the getting started ng.
Thanks
Frank Polan

Frank,
I was not trying to patronize. I was trying to lighten things up. My
apologies if you found it offensive.

[Geoff Wass [dBVIPS]]

Post by Frank J. Polan
Geoff
I did a <g>
No apologies necessary
Frank Polan

Frank,

I wasn't sure if it was for the whole paragraph or just the last
comment. I'm glad everything's OK.

[Bruce R. Roland]

Geoff

Post by Geoff Wass [dBVIPS]
As Bruce has said, it is very easily abused. There is a tendency of
former DOS programmers to just convert all public variables to _app
properties and move on. The problems are not obvious at first.

Thnaks for the plug - I think! I do get that the _app object can be used incorrectly - I think I am haveing difficulty in understanding what is and is not incorrect and although I do not speak for Frank it sems he is having more of an issuse whith the opinions surrounding the same We all like to think we got it - but then tomorrow something always seems to happen to change our opinions.

Bruce

[Frank J. Polan]

Bruce

I've been using it since it became available, without any problems.

My message was meant to spark some discussion for your, and other new
users, benefit.

I guess I was in a bad mood at the time<g> but I felt the initial
response given to your question was far to simplistic

Hope some of the discussion helped

Now I'll go back to billable work

Frank Polan


On Sat, 29 Nov 2008 11:13:13 -0500, Bruce R. Roland

Post by Bruce R. Roland
Geoff

Post by Geoff Wass [dBVIPS]
As Bruce has said, it is very easily abused. There is a tendency of
former DOS programmers to just convert all public variables to _app
properties and move on. The problems are not obvious at first.

Thnaks for the plug - I think! I do get that the _app object can be used incorrectly - I think I am haveing difficulty in understanding what is and is not incorrect and although I do not speak for Frank it sems he is having more of an issuse whith the opinions surrounding the same We all like to think we got it - but then tomorrow something always seems to happen to change our opinions.
Bruce

[Geoff Wass [dBVIPS]]

Post by Bruce R. Roland
Geoff

Post by Geoff Wass [dBVIPS]
As Bruce has said, it is very easily abused. There is a tendency of
former DOS programmers to just convert all public variables to _app
properties and move on. The problems are not obvious at first.

Thnaks for the plug - I think! I do get that the _app object can be used incorrectly - I think I am haveing difficulty in understanding what is and is not incorrect and although I do not speak for Frank it sems he is having more

of an issuse whith the opinions surrounding the same We all like to think we got it - but then tomorrow something always seems to happen to change our opinions.

Post by Bruce R. Roland
Bruce

Bruce,

Since you are learning right now, it is enough to know you should be
careful. If you can justify using, then use it. However, until you get
past the beginner level, I don't think you will need to worry about
attaching much if anything to it. You will, from time to time, reference
what is already given to you in the _app object.

Don't let this side conversation about the finer details of _app
distract you from doing what you need to do. In news groups it is not
unusual for one conversation to fragment into several new ones. It is
like sitting at a table with a group of friends. You may all start by
sharing a single conversation for a while, but it is not unusual for
smaller conversations to start. You can enjoy your conversation without
knowing what the friends next to you are saying. At the same time, you
can listen in on neighboring conversation, if you like, or join in later
on.

[Bruce R. Roland]

Geoff

Post by Geoff Wass [dBVIPS]
Since you are learning right now, it is enough to know you should be
careful. If you can justify using, then use it. However, until you get
past the beginner level, I don't think you will need to worry about
attaching much if anything to it. You will, from time to time, reference
what is already given to you in the _app object.
Don't let this side conversation about the finer details of _app
distract you from doing what you need to do. In news groups it is not
unusual for one conversation to fragment into several new ones. It is
like sitting at a table with a group of friends. You may all start by
sharing a single conversation for a while, but it is not unusual for
smaller conversations to start. You can enjoy your conversation without
knowing what the friends next to you are saying. At the same time, you
can listen in on neighboring conversation, if you like, or join in later
on.

What you are saying is that it takes on a life of its own - and your right. While the aside conversations are good to follow - they don't always help the nebie si all - they may tend to confuse more. And yet as you say the newbie must be aware to some degree the of diffiring opinions if for no other reason so as to have a base from which to sort it all later.

With my own programs I know they need some more work - and yet the one thing I am getting the more I see here is that I may not be so far off the mark as I thought I was with my code - However, I probable am way out in left field with respect to nomenclature (i.e., caslling things by their proper name or referring to things correctly).

In all my programs - even in DOS - the one thing I always liked to do was have as little code as possible and have as much of my code common to my application so the only thing I needed to do to add a new (for lack of a better word here) database was simply to create a form - a report and the tables for the data and everything else was the same (common across the application.

The common code I always put in a single file (program). This is what I do here and from what I am hearing here and reading in Ken's bokk - it seems that for all intentional purposes this program as I have it is an _app object - albeit I don't call it that. So I do - it seems - have a way to go but it also seems I am on my way in the right direction. I will need to learn more before I get there thouigh or can proceed further in that direction. That's all!

Bruce

[Geoff Wass [dBVIPS]]

Post by Bruce R. Roland
Geoff

Post by Geoff Wass [dBVIPS]
Since you are learning right now, it is enough to know you should be
careful. If you can justify using, then use it. However, until you get
past the beginner level, I don't think you will need to worry about
attaching much if anything to it. You will, from time to time, reference
what is already given to you in the _app object.
Don't let this side conversation about the finer details of _app
distract you from doing what you need to do. In news groups it is not
unusual for one conversation to fragment into several new ones. It is
like sitting at a table with a group of friends. You may all start by
sharing a single conversation for a while, but it is not unusual for
smaller conversations to start. You can enjoy your conversation without
knowing what the friends next to you are saying. At the same time, you
can listen in on neighboring conversation, if you like, or join in later
on.

What you are saying is that it takes on a life of its own - and your right. While the aside conversations are good to follow - they don't always help the nebie si all - they may tend to confuse more. And yet as you say the

newbie must be aware to some degree the of diffiring opinions if for no other reason so as to have a base from which to sort it all later.

Post by Bruce R. Roland
With my own programs I know they need some more work - and yet the one thing I am getting the more I see here is that I may not be so far off the mark as I thought I was with my code - However, I probable am way out in left field

with respect to nomenclature (i.e., caslling things by their proper name or referring to things correctly).

Post by Bruce R. Roland
In all my programs - even in DOS - the one thing I always liked to do was have as little code as possible and have as much of my code common to my application so the only thing I needed to do to add a new (for lack of a better

word here) database was simply to create a form - a report and the tables for the data and everything else was the same (common across the application.

Post by Bruce R. Roland
The common code I always put in a single file (program). This is what I do here and from what I am hearing here and reading in Ken's bokk - it seems that for all intentional purposes this program as I have it is an _app object -

albeit I don't call it that. So I do - it seems - have a way to go but it also seems I am on my way in the right direction. I will need to learn more before I get there thouigh or can proceed further in that direction. That's
all!

Post by Bruce R. Roland
Bruce

Bruce,

Once you get the hang of object you will like them because they are
meant to be reused.

[Bruce R. Roland]

Geoff

Post by Geoff Wass [dBVIPS]
Once you get the hang of object you will like them because they are
meant to be reused.

Unless I miss the mark here - I take this as a confirmation that I am on the right track to some degree.

Now if I can only get the same reusability to work for me with respect to classes - or maybe I already am and don't realize that either!

Bruce

[Geoff Wass [dBVIPS]]

Post by Bruce R. Roland
Geoff

Post by Geoff Wass [dBVIPS]
Once you get the hang of object you will like them because they are
meant to be reused.

Unless I miss the mark here - I take this as a confirmation that I am on the right track to some degree.
Now if I can only get the same reusability to work for me with respect to classes - or maybe I already am and don't realize that either!
Bruce

Bruce,

You are on the right track. As you develop more and more classes you
will see opportunities to reuse old ones, especially if you make your
classes with an eye to reusability.

[Greg Neid]

Hi Greg,
_app.aStuff = new array()

This works too!

Greg

Post by Greg Hill

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------

Lets look at the alternative.
My app starts, I prompt the user for login credentials, this requires an
open table and a lookup, so if he successfully logs in, why should I leave
that table open? Why not store it to _app.userid or something? That is what
I do and it works perfectly.
If one does not store it in a system accessible like object or variable,
then he or she would have to resort to leaving that table opened and hope
that the record pointer doesn't get moved and also invite record locking
issues, along with more memory. Also, if the record pointer gets moved it
would cause errors when referencing user attributes. By the way, I use the
userid information in many places throughout the application.
I use the heck out of the _app object and have never ever had one problem
with it. I also use public variable for arrays primarily (now that I might
do differently someday) but not because it causes me issues, only because it
is not as dynamic as building arrays each time a form is opened, which could
also be argued depending on the size of the array.
I have not experienced one reason to "not" use the _app object and actually
same goes for public variables, they work as long as you work them.
Greg Hill

[Greg Hill]

Post by Greg Neid
Hi Greg,
_app.aStuff = new array()
This works too!

That is true and I do have both in my app. I migrated from 5.7 and kept a
bunch of the arrays the way they were. Someday I will change them but I
will probably do away with having them as constant arrays and change most of
them over to arrays that are created on the open of forms and such.


Greg Hill

[Greg Hill]

Post by Greg Neid
Hi Greg,
Much of my work is with web applications. So, when you get a transaction,
you check the sessions table, then, the app control table, then the user
table. What i do is then store all of that info into _app variable or, in
some cases objects that have been created for this purpose. eg.
control = new object()
session = new object()
user = new object()
Then add the data as new properties of the object. the _app variable can
work the same way.
Altough the application makes extensive use of encapsulation, the
behavious of the app overall is dependent on the data in the app control
table. the security is dependent on the data cooming from the user table
and the previous information, timing loops etc. comes form the session
table. And, this information is required by many of the objects, even
though they are encapsulated.
I do not like public varibles, because there is always a problem with
namiing things incorrectly later and over-writing a variable. Creating
varibales on the fly is both >a strength and a weakness of dBase.

In the following, x will be a private variable and not a system wide object.
x = new object()

So in order to use x the way one would use _app you would have to make x
public. Of course you could store everything you need to this object rather
than multiple public variables but you end up back at the same problem.

Greg Hill

[Greg Neid]

Hi Greg,

Yes and no. Variables that are created without a scope definition are "PRIVATE".

If you are not using new classes (and this can be done very well in web apps) because there are no forms, menus or popups "variables created in higher routines are visible in lower level routines" (quote from dBase OLH in Private variables). The OLH for Public shows the scope for all variable types and here is a quote form OLH-PUBLIC:
"Public variables are rarely used in programs. To maintain global values, it’s better to create properties of the _app object. As properties, they will not conflict with variables that you might have with the same name, and they can communicate with each other more easily."

Post by Greg Hill
In the following, x will be a private variable and not a system wide object.
x = new object()
So in order to use x the way one would use _app you would have to make x
public. Of course you could store everything you need to this object rather
than multiple public variables but you end up back at the same problem.
Greg Hill

[Greg Hill]

Post by Greg Neid
Hi Greg,
Yes and no. Variables that are created without a scope definition are "PRIVATE".
If you are not using new classes (and this can be done very well in web
apps) because there are no forms, menus or popups "variables created in
higher routines >are visible in lower level routines" (quote from dBase
OLH in Private variables). The OLH for Public shows the scope for all

Good point, that is something I wouldn't think much about in a windows app.
I see how in a web app it would be very useful, but then again<g> if
private variables can be seen throughout the whole app, we could technically
call them public and they would fall under the same rules as a public var.

Post by Greg Neid
"Public variables are rarely used in programs. To maintain global values,
it's better to create properties of the _app object. As properties, they
will not conflict with >variables that you might have with the same name,
and they can communicate with each other more easily."

Ah, you see the online help pointing us to build upon the _app object, thank
you for pointing that out.

Greg Hill

[Greg Neid]

Hi Greg,

Much of my work is with web applications. So, when you get a transaction, you check the sessions table, then, the app control table, then the user table. What i do is then store all of that info into _app variable or, in some cases objects that have been created for this purpose. eg.

control = new object()
session = new object()
user = new object()

Then add the data as new properties of the object. the _app variable can work the same way.

Altough the application makes extensive use of encapsulation, the behavious of the app overall is dependent on the data in the app control table. the security is dependent on the data cooming from the user table and the previous information, timing loops etc. comes form the session table. And, this information is required by many of the objects, even though they are encapsulated.

I do not like public varibles, because there is always a problem with namiing things incorrectly later and over-writing a variable. Creating varibales on the fly is both a strength and a weakness of dBase.

Good luck.

Greg Neid

Post by Greg Hill

Post by Greg Neid
Hi Greg,
_app.aStuff = new array()
This works too!

That is true and I do have both in my app. I migrated from 5.7 and kept a
bunch of the arrays the way they were. Someday I will change them but I
will probably do away with having them as constant arrays and change most of
them over to arrays that are created on the open of forms and such.
Greg Hill

[Andrew Shimmin]

What topic in the "Getting started" newsgroup are you referring to?

The _app object is unique to each instance of an application controlled by the runtime, so using it for variable management is a good strategy and will pose no problems among multiple applications and multiple users on the same system. I have used it extensively for years and had no problems.

Running multiple applications controlled by the IDE will cause problems since the _app object is no longer unique to each instance of the application.

regards, andrew

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------
The above values are checked as required when opening a menu item or
form
Thanks
Frank Polan

[Frank J. Polan]

Andrew

Here's a few quotes from the ng. The first is the one that annoyed me
and prompted my question. The others are more moderate but I'm still
trying to find why it's not recommended for the way I, and the others
who responded here, are using it

Thanks

Frank Polan

----------------------------------------------------------------------------------------
NO! NO! NO!
Hanging things to "_app." is no *alternative* at all.
It's just the very same bad behaviour (or should I say what I really
think: "the very same nonsense"??)

-------------------------
For instance, I used _app variables a fair bit in the past, but no
more.
I have learned how useful it is to have a properly encapsulated object
(no external dependencies), so I make the effort to do it.
---------------------------------------
Yes, the _app can be useful. I am not saying you absolutely shouldn't
use it (this is where I differ with Rainald), but I am saying you
should
try to not use it or at least use it very prudently. As I said, by
avoiding _app properties, PUBIC variables and your runtime tables
leads
to better object-oriented programming. Encapsulation is part of OOP
and
relying upon values which are external to the object (ex: _app
properties) breaks encapsulation. A fully encapsulated object is a
more
reuseable object. It allows the object to be tested independent of the
---------------------------------------------------------
On Sat, 29 Nov 2008 08:39:34 +1100, Andrew Shimmin

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?
The _app object is unique to each instance of an application controlled by the runtime, so using it for variable management is a good strategy and will pose no problems among multiple applications and multiple users on the same system. I have used it extensively for years and had no problems.
Running multiple applications controlled by the IDE will cause problems since the _app object is no longer unique to each instance of the application.
regards, andrew

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------
The above values are checked as required when opening a menu item or
form
Thanks
Frank Polan

[Frank J. Polan]

Andrew

On Sat, 29 Nov 2008 09:33:56 +1100, Andrew Shimmin

If code is going to be fully encapsulated the author has a point.
I use the _app object to ONLY hold application object properties, everything else is held as a property in an object or as a local/private variable for execution sequence control only.

That's how I use it as well.
That's why I thought it was unfair to the user who asked the question
to "shut him off" from a very useful programming technique

I've said my piece and I'm done with it now

Thanks

Frank Polan

[Andrew Shimmin]

Frank,

Ok ... I think I can see the problem, however I still do not have the full context of the quotes.

Post by Frank J. Polan
NO! NO! NO!
Hanging things to "_app." is no *alternative* at all.
It's just the very same bad behaviour (or should I say what I really
think: "the very same nonsense"??)
For instance, I used _app variables a fair bit in the past, but no
more.
I have learned how useful it is to have a properly encapsulated object
(no external dependencies), so I make the effort to do it.
---------------------------------------
Yes, the _app can be useful. I am not saying you absolutely shouldn't
use it (this is where I differ with Rainald), but I am saying you
should
try to not use it or at least use it very prudently. As I said, by
avoiding _app properties, PUBIC variables and your runtime tables
leads
to better object-oriented programming. Encapsulation is part of OOP
and
relying upon values which are external to the object (ex: _app
properties) breaks encapsulation. A fully encapsulated object is a
more
reuseable object. It allows the object to be tested independent of the

If code is going to be fully encapsulated the author has a point.

I use the _app object to ONLY hold application object properties, everything else is held as a property in an object or as a local/private variable for execution sequence control only.

Getting your head around encapsulation can take time and "hanging variables off the _app object" is a good way to learn it. Eventually the penny drops and the OBJECT object becomes very useful.

Each developer is at a different stage of their OOP learning curve so different strokes for different folks.

regards, andrew

Post by Frank J. Polan
Andrew
Here's a few quotes from the ng. The first is the one that annoyed me
and prompted my question. The others are more moderate but I'm still
trying to find why it's not recommended for the way I, and the others
who responded here, are using it
Thanks
Frank Polan
----------------------------------------------------------------------------------------
NO! NO! NO!
Hanging things to "_app." is no *alternative* at all.
It's just the very same bad behaviour (or should I say what I really
think: "the very same nonsense"??)
-------------------------
For instance, I used _app variables a fair bit in the past, but no
more.
I have learned how useful it is to have a properly encapsulated object
(no external dependencies), so I make the effort to do it.
---------------------------------------
Yes, the _app can be useful. I am not saying you absolutely shouldn't
use it (this is where I differ with Rainald), but I am saying you
should
try to not use it or at least use it very prudently. As I said, by
avoiding _app properties, PUBIC variables and your runtime tables
leads
to better object-oriented programming. Encapsulation is part of OOP
and
relying upon values which are external to the object (ex: _app
properties) breaks encapsulation. A fully encapsulated object is a
more
reuseable object. It allows the object to be tested independent of the
---------------------------------------------------------
On Sat, 29 Nov 2008 08:39:34 +1100, Andrew Shimmin

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?
The _app object is unique to each instance of an application controlled by the runtime, so using it for variable management is a good strategy and will pose no problems among multiple applications and multiple users on the same system. I have used it extensively for years and had no problems.
Running multiple applications controlled by the IDE will cause problems since the _app object is no longer unique to each instance of the application.
regards, andrew

Post by Frank J. Polan
There has been some discussion in the Getting Started group about the
inadvisability of using Public variables and _app objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in the use
of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree with
using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login per
user/PC, the following can't change -
userid, security level, physical location.
----------------------------------------------------------------------------------
The above values are checked as required when opening a menu item or
form
Thanks
Frank Polan

[Rainald]

Post by Andrew Shimmin
Ok ... I think I can see the problem, however I still do not have
the full context of the quotes.

The context of the controversy (which was the reason for Frank to put it
in here) started in "getting started" in Bruce R. Roland's thread "Can't
seem to get single2.wfm code to run right" where Geoff Wass in his
posting of Nov. 25 06:21 news://news.dbase.com/***@news.dbase.com
pointed the usage of PUBLIC variables:
"It sounds from your description that you are using
PUBLIC variables with OOP programming. This is not a
recommended thing to do if you are doing it. OOP is
based on the concept that every object is a independent
unit. It contains or receives directly everything it
needs. It should never rely upon things in its
"environment" like we often did in the old days
of procedural programming in the DOS versions of dBASE."

When Bruce asked back, I jumped in and did second this news://news.dbase.com/***@news-server and tried to explain
why PUBLIC variable should be avoided in OOP dBASE in any case.
On a posting by Bruce asking back, Frank jumped in recommending hanging
variables to _app as an "equivalent of public variables".
This to me did not seem too good a suggestion, especially for a user who
is not yet to deep in OOP-programming.

So I replied saying
"... It's OK to attach some centrally used *OBJECTs*
(which are used in an application *throughout*) to
"_app."
But placing any "properties" just for handling problems
with the scope of variables there is as bad as using
PUBLICs. Just very poor design. As I used to say/pray
(just to quote myself <gbg>): "Hanging properties at
"_app." is nothing but using OOPish painted PUBLICs".
The one is as bad as the other ..."

After some a number of further postings on a remark of Geoff (who shared
my approach to the issue):

"As I described above, it is the suggested alternative
to public variables."

Post by Andrew Shimmin

Post by Frank J. Polan
NO! NO! NO!
Hanging things to "_app." is no *alternative* at all.
It's just the very same bad behaviour (or should I say what I
really think: "the very same nonsense"??)

I admit that this - written very late in the night in angry mood - was
not only a bit overdrawn. {siiiigh}
That Frank just used this quote (without the context) IMO is really
tendentious. It was clear for all participants of the discussion that I
did only object to using properties of _app in the same way (as an
equivalent for) PUBLIC variables.

There can be no doubt that I never objected to the usage of *objects*
attached to _app, when used carefully and "thrifty as a Scotchman". And

Post by Andrew Shimmin

Post by Frank J. Polan
For instance, I used _app variables a fair bit in the past, but no
more.
I have learned how useful it is to have a properly
encapsulated object (no external dependencies), so I
make the effort to do it.
---------------------------------------
Yes, the _app can be useful. I am not saying you
absolutely shouldn't use it (this is where I differ
with Rainald), but I am saying you should try to not
use it or at least use it very prudently. As I said, by
avoiding _app properties, PUBIC variables and your
runtime tables leads to better object-oriented programming.
Encapsulation is part of OOP and relying upon values
which are external to the object (ex: _app properties)
breaks encapsulation. A fully encapsulated object is a
more reuseable object. It allows the object to be tested
independent of the independent of the external values
it relies upon. If you start sub-classing (a.k.a.
extending) over and over a class which has a reliance on
an _app variable, you may easily forget this external
dependency when you are trying to debug the offspring.

If code is going to be fully encapsulated the author has a point.

This is my *main* point.
Hanging properties to _app IMO is hardly different at all from using
PUBLICs - as I use to say "just OOPish painted PUBLICs".

Post by Andrew Shimmin
I use the _app object to ONLY hold application object properties,
everything else is held as a property in an object or as a
local/private variable for execution sequence control only.

Values held in objects is a better way. Still there may problems be
arising if one works with subclassing.
Someway it's still breaking OOP-basics and may be seen as neglecting the
fact that classes should be "self-contained".

Post by Andrew Shimmin
Getting your head around encapsulation can take time and "hanging
variables off the _app object" is a good way to learn it.
Eventually the penny drops and the OBJECT object becomes very
useful.
Each developer is at a different stage of their OOP learning curve
so different strokes for different folks.

I fully agree.

Rainald

Post by Andrew Shimmin

Post by Frank J. Polan
Andrew
Here's a few quotes from the ng. The first is the one that annoyed
me and prompted my question. The others are more moderate but I'm
still trying to find why it's not recommended for the way I, and
the others who responded here, are using it
Thanks
Frank Polan
---------------------------------------------------------------------

-------------------

Post by Andrew Shimmin

Post by Frank J. Polan
NO! NO! NO!
Hanging things to "_app." is no *alternative* at all.
It's just the very same bad behaviour (or should I say what I
really think: "the very same nonsense"??)
-------------------------
For instance, I used _app variables a fair bit in the past, but no
more.
I have learned how useful it is to have a properly encapsulated
object (no external dependencies), so I make the effort to do it.
---------------------------------------
Yes, the _app can be useful. I am not saying you absolutely
shouldn't use it (this is where I differ with Rainald), but I am
saying you should
try to not use it or at least use it very prudently. As I said, by
avoiding _app properties, PUBIC variables and your runtime tables
leads
to better object-oriented programming. Encapsulation is part of OOP
and
relying upon values which are external to the object (ex: _app
properties) breaks encapsulation. A fully encapsulated object is a
more
reuseable object. It allows the object to be tested independent of
the ---------------------------------------------------------
On Sat, 29 Nov 2008 08:39:34 +1100, Andrew Shimmin

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?
The _app object is unique to each instance of an application
controlled by the runtime, so using it for variable management is
a good strategy and will pose no problems among multiple
applications and multiple users on the same system. I have used
it extensively for years and had no problems.
Running multiple applications controlled by the IDE will cause
problems since the _app object is no longer unique to each
instance of the application.
regards, andrew

Post by Frank J. Polan
There has been some discussion in the Getting Started group
about the inadvisability of using Public variables and _app
objects
Public variables - no problem - never used them even in the DOS
version
I'm reporting my question here about the use of the _app object
because I'm seriously interested in any potential downside in
the use of the _app object in the _specific_ example I've used
-------------- original question <snipped> ---------------
Maybe a new thread, but I'd be interested in why you don't agree
with using the _app object as dBASE seemed to design it -
system/application wide CONSTANT values/settings
In a compiled app, after a successful login, and only one login
per user/PC, the following can't change -
userid, security level, physical location.
-------------------------------------------------------------------

---------------

Post by Andrew Shimmin

Post by Frank J. Polan

Post by Andrew Shimmin

Post by Frank J. Polan
The above values are checked as required when opening a menu
item or form
Thanks
Frank Polan

[Rainald]

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?

pls see my parallel posting.

Post by Andrew Shimmin
The _app object is unique to each instance of an application
controlled by the runtime, so using it for variable management is a
good strategy and will pose no problems among multiple applications
and multiple users on the same system.

That's clear! But this is not the really important point.

Post by Andrew Shimmin
I have used it extensively for years and had no problems.

I fully agree that no problems arise with other applications and other
users.

Post by Andrew Shimmin
Running multiple applications controlled by the IDE will cause
problems since the _app object is no longer unique to each instance
of the application.

Yes, there's that too.
But the main issue is - as Geoff Wass and Ken Mayer have explained - the
influence on encapsulation and by this the re-usability of classes.
Whatever is hanging at app is *global* and this may be disturbing.

Rainald

[Frank J. Polan]

Rainald

If you want to talk theory, as I said in another post, the only
theoretically possible truly encapsulated object is a single purpose
embedded system on a chip, which still generally rely on external
inputs.
All useable applications rely on input from an external source,
usually the user, so the encapsulation comes after the fact. Most, if
not all, "black box" classes rely on external arguments to perform
their functions.. So how does this effect their reusability

Frank Polan

Post by Rainald

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?

pls see my parallel posting.

Post by Andrew Shimmin
The _app object is unique to each instance of an application
controlled by the runtime, so using it for variable management is a
good strategy and will pose no problems among multiple applications
and multiple users on the same system.

That's clear! But this is not the really important point.

Post by Andrew Shimmin
I have used it extensively for years and had no problems.

I fully agree that no problems arise with other applications and other
users.

Post by Andrew Shimmin
Running multiple applications controlled by the IDE will cause
problems since the _app object is no longer unique to each instance
of the application.

Yes, there's that too.
But the main issue is - as Geoff Wass and Ken Mayer have explained - the
influence on encapsulation and by this the re-usability of classes.
Whatever is hanging at app is *global* and this may be disturbing.
Rainald

[Rainald]

Post by Frank J. Polan
If you want to talk theory, as I said in another post, the only
theoretically possible truly encapsulated object is a single
purpose embedded system on a chip, which still generally rely on
external inputs.

It's one of the basic techniques of rhetoric that in a discussion any
argument can be made invalid by treating it "ad absurdum" (to an absurd
end) by using an extreme pattern. <g&d>

Honestly speaking encapsulation in the world of OOP does not at all mean
something like an embedded chip..

Post by Frank J. Polan
All useable applications rely on input from an external source,
usually the user, so the encapsulation comes after the fact.

No, not "after the fact". Applications work with input, be it the user,
a database or other data.
Encapsulation in so far means that the object holds the data and what's
held inside the object is not seen from outside (from another object)
unless there's channels for communications established in the object.
In "true" OOP-languages (not so in dBASE which only has apart of
OOP-technologies built-in) therefore "messages" sent to objects and
asked for by objects play a major role.

The main thing with "input" is that the object itself is collecting the
information needed (the Form asks for User-input, the datamodule gathers
the data) OR the information is handed over and/or collected in a way
controlled by the object.

Thanks to Randy Solton and his team in 32-bit dBASE there are better
ways for the communication of objects than in dBWIN/VdB 5.7. An object
can look around for an object it wants to reach (to send or request
information). Therefore - to come back to the topic of this thread - a
"switchboard" created in the old days by attaching object-references to
_app (see f.e. Alan Katz' classic "Manager.cc") nowadays is not *needed*
anymore. The objects can talk to each other directly and send or request
information.

Post by Frank J. Polan
Most,
if not all, "black box" classes rely on external arguments to
perform their functions.. So how does this effect their reusability

Not the usage of "external" information (requested or sent through
pre-defined channels) does effect re-usability. It's they way the
information gets to (into) the object. It really matters if an object is
tied to another object. External dependencies are what hurts.

I hope this does not appear as too much of a "lecture" again ;-)
You might ask Geoff again (with whom I fully agree) - he perhaps might
say in "easier" words arriving at the same results.

Apart: dBASE has always really flexible and forgiving. And it has always
offered many ways of doing things. IMO even the OOP-basics in dBASE must
not be seen too dogmatic.

Let me repeat that I never said one must not use objects attached to
_app.
I'm a bit more strict if it comes to properties as those in fact are not
much different from PUBLIC variables (well, except being protected from
a RELEASE ALL <bg>).

Rainald

Post by Frank J. Polan

Post by Rainald

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?

pls see my parallel posting.

Post by Andrew Shimmin
The _app object is unique to each instance of an application
controlled by the runtime, so using it for variable management is
a good strategy and will pose no problems among multiple
applications and multiple users on the same system.

That's clear! But this is not the really important point.

Post by Andrew Shimmin
I have used it extensively for years and had no problems.

I fully agree that no problems arise with other applications and
other users.

Post by Andrew Shimmin
Running multiple applications controlled by the IDE will cause
problems since the _app object is no longer unique to each
instance of the application.

Yes, there's that too.
But the main issue is - as Geoff Wass and Ken Mayer have explained
- the influence on encapsulation and by this the re-usability of
classes. Whatever is hanging at app is *global* and this may be
disturbing.
Rainald

[Frank J. Polan]

Rainald

Post by Rainald
It's one of the basic techniques of rhetoric that in a discussion any
argument can be made invalid by treating it "ad absurdum" (to an absurd
end) by using an extreme pattern. <g&d>

I think I leaned that from someone here - I wonder who <g>

Post by Rainald
Honestly speaking encapsulation in the world of OOP does not at all mean
something like an embedded chip..

I know that, but we were dealing in extremes

Post by Rainald

Post by Frank J. Polan
All useable applications rely on input from an external source,
usually the user, so the encapsulation comes after the fact.

No, not "after the fact". Applications work with input, be it the user,
a database or other data.
Encapsulation in so far means that the object holds the data and what's
held inside the object is not seen from outside (from another object)
unless there's channels for communications established in the object.
In "true" OOP-languages (not so in dBASE which only has apart of
OOP-technologies built-in) therefore "messages" sent to objects and
asked for by objects play a major role.
The main thing with "input" is that the object itself is collecting the
information needed (the Form asks for User-input, the datamodule gathers
the data) OR the information is handed over and/or collected in a way
controlled by the object.

I disagree The form class doesn't ask for input, it waits for a
message to be sent. Until a message is received it can do nothing. An
object running on a timer, like an embedded application, asks or
searches for input and can act differently depending on whether or not
it receives it.

Post by Rainald
Thanks to Randy Solton and his team in 32-bit dBASE there are better
ways for the communication of objects than in dBWIN/VdB 5.7. An object
can look around for an object it wants to reach (to send or request
information). Therefore - to come back to the topic of this thread - a
"switchboard" created in the old days by attaching object-references to
_app (see f.e. Alan Katz' classic "Manager.cc") nowadays is not *needed*
anymore. The objects can talk to each other directly and send or request
information.

Post by Frank J. Polan
Most,
if not all, "black box" classes rely on external arguments to
perform their functions.. So how does this effect their reusability

Not the usage of "external" information (requested or sent through
pre-defined channels) does effect re-usability. It's they way the
information gets to (into) the object. It really matters if an object is
tied to another object. External dependencies are what hurts.
I hope this does not appear as too much of a "lecture" again ;-)
You might ask Geoff again (with whom I fully agree) - he perhaps might
say in "easier" words arriving at the same results.
Apart: dBASE has always really flexible and forgiving. And it has always
offered many ways of doing things. IMO even the OOP-basics in dBASE must
not be seen too dogmatic.
Let me repeat that I never said one must not use objects attached to
_app.
I'm a bit more strict if it comes to properties as those in fact are not
much different from PUBLIC variables (well, except being protected from
a RELEASE ALL <bg>).

In any cas,e this discussion was never about encapsulation of objects
,on which subject I agree with you; it was about encapsulation of
applications. _app object - as in application, on which I don't agree
with you

We'll just have to agree to disagree

Thanks

Frank Polan

Post by Rainald
Rainald

Post by Frank J. Polan

Post by Rainald

Post by Andrew Shimmin
What topic in the "Getting started" newsgroup are you referring to?

pls see my parallel posting.

Post by Andrew Shimmin
The _app object is unique to each instance of an application
controlled by the runtime, so using it for variable management is
a good strategy and will pose no problems among multiple
applications and multiple users on the same system.

That's clear! But this is not the really important point.

Post by Andrew Shimmin
I have used it extensively for years and had no problems.

I fully agree that no problems arise with other applications and
other users.

Post by Andrew Shimmin
Running multiple applications controlled by the IDE will cause
problems since the _app object is no longer unique to each
instance of the application.

Yes, there's that too.
But the main issue is - as Geoff Wass and Ken Mayer have explained
- the influence on encapsulation and by this the re-usability of
classes. Whatever is hanging at app is *global* and this may be
disturbing.
Rainald

[Bruce R. Roland]

Hello all,

I think it was a question (or maybe an example of my code) which started this thread.

I have been trying to follow it some but for me as a newbie it is a little difficult as I am not fully in touch with the nomenclature yet. However, after reading something in Ken's book and some of this thread it seems - if I have it right - that the _app object is no more than what could essentially be termed a startup for an application. Without having studied Ken's example in his book - but having just precursored it - it seems like this is where one would put such things as startup menus and - say - form templates which would be the basis for form across several tables and uses - for example.

If this is the case then I would have to say I am to a point of degree already using such (an _app object) but didn't know it as I have a standard template upon which all my forms are based and it is - along with startuo menus - all contained in one program.

This would maybe make sense as well since the public variable I use and had given in my code samples are all withing my form programs which I think would be the "encapsulation" to which some of you are referring and talking about.

I don't know if this synopsis is corrrect or not but I think it is somewhat along what you all are discussing.

Bruce

[Ken Mayer [dBVIPS]]

Post by Bruce R. Roland
Hello all,
I think it was a question (or maybe an example of my code) which started this thread.
I have been trying to follow it some but for me as a newbie it is a little difficult as I am not fully in touch with the nomenclature yet. However, after reading something in Ken's book and some of this thread it seems - if I have it right - that the _app object is no more than what could essentially be termed a startup for an application. Without having studied Ken's example in his book - but having just precursored it - it seems like this is where one would put such things as startup menus and - say - form templates which would be the basis for form across several tables and uses - for example.

Basically, the _app object is an object that has a small amount of
pre-defined functionality, but more importantly, it is an object that is
*always* available in the application, from wherever you are. Therefore,
you can add custom properties and methods to it, and be able to call
them from anywhere in the application.

The trap that I think most people run into is that public variables, or
in this case public properties of the _app object can be problematic in
that if you are not *very* careful as a programmer, you can trip
yourself up -- overwrite the value without trying, that kind of thing.
It can really cause problems.

Ultimately, object oriented coding is really about encapsulating your
code so that you create objects with re-usable code in them, but
everything that is necessary for them to work is either passed to them
(values assigned to custom properties, etc.) or is in the object's
definition somehow. This is a great idea, not always easy to do ... <g>

Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/

*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase/dBASEBooks.htm
http://www.goldenstag.net/dbase

[Jan Hoelterling]

Hi Frank,

I use _app exactly as you describe, but with a few more (self-imposed)
restrictions:

1) I never create a property directly under _app. I always create an object
to "group" items. For example, my application will create:
_app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)

2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between forms -
which would have resulted in a public variable. For all of the reasons
already discussed here, I don't do that.

I have not had any problems doing things this way and don't see a reason to
change it

Jan

[Frank J. Polan]

Jan

I like your enhancement. I'll take a further look at it.

Like you I never use the _app object for communicating between forms,
only to check user permissions, etc, before opening a form, or
displaying options. Easier than modifying the menu on the fly<g>

Thanks for your reply

Frank Polan

On Sat, 29 Nov 2008 17:43:38 -0600, "Jan Hoelterling"

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more (self-imposed)
1) I never create a property directly under _app. I always create an object
_app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between forms -
which would have resulted in a public variable. For all of the reasons
already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a reason to
change it
Jan

[Rainald]

Jan Hoelterling wrote:

Hallo Jan,
the culprit in this case was me :-( :-( -pls see my parallel reply to
Andrew Shimming.
The controversy did not arise, however, because I would have totally
denied the usage of _app as place for references. It only came up on
using properties as a replacement of PUBLIC variables (you might
remember my "ideology" in so far <g>).

Post by Jan Hoelterling
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
_app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)

One can do it this way. Agreed.
Still I see problems in the same direction as Geoff Wass and Ken Mayer
have named them.
Classes based on that IMO are not independent enough.
I think that a device might be to make objects (the classes they are
deriving from) as self-contained as possible.

Post by Jan Hoelterling
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all of
the reasons already discussed here, I don't do that.

This is a most important point!!
Contrary to the old VdB 5.x, 32-bit dBASE now has enough instruments for
enabling *direct* communications between objects. As they can look
around for other object themselves and contact them, a switchboard - as
often implemented by objects hang at _app (so f.e. in Alan Katz' early
applications) is no longer needed.

Rainald

[Glenn Johansen]

and I store the current form that has focus.

_app.currentform

- glenn

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more (self-imposed)
1) I never create a property directly under _app. I always create an
_app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between forms -
which would have resulted in a public variable. For all of the reasons
already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a reason
to change it
Jan

[Frank J. Polan]

Rainald

Don't know what Glenn uses it for , but my "encapsulated" speedbar
works on the currentForm.rowset

Frank Polan

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Out of which reason?
What are you doing with that afterwards?
Rainald

Post by Glenn Johansen

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
an object to "group" items. For example, my application will
create: _app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all of
the reasons already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a
reason to change it
Jan

[Frank J. Polan]

Rainald

The toolbar( or speedbar) is attached to the _app.framewin. The
toolbar's onUpdate picks up its arguments from the _app.currentForm,
and the _app.currentForm.Rowset to decide which buttons to activate.
This way it works with every form in the app with no modifications to
the toolbar

Frank Polan

Post by Frank J. Polan
Don't know what Glenn uses it for , but my "encapsulated" speedbar
works on the currentForm.rowset

Sorry I can not see what you are using in which way :-( :-(
Rainald

Post by Frank J. Polan

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Out of which reason?
What are you doing with that afterwards?
Rainald

Post by Glenn Johansen

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
an object to "group" items. For example, my application will
create: _app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all
of the reasons already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a
reason to change it
Jan

[Rainald]

Frank J. Polan wrote:

[Glenn Johansen]

Post by Frank J. Polan

Post by Frank J. Polan

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

[Rainald]

Post by Frank J. Polan

Post by Frank J. Polan

Out of which reason?
What are you doing with that afterwards?

[Frank]

Post by Frank J. Polan

Post by Frank J. Polan
Don't know what Glenn uses it for , but my "encapsulated" speedbar
works on the currentForm.rowset

[Rainald]

Post by Frank J. Polan

Sorry I can not see what you are using in which way :-( :-(

[Rank]

Post by Frank J. Polan
The toolbar( or speedbar) is attached to the _app.framewin. The
toolbar's onUpdate picks up its arguments from the _app.currentForm,
and the _app.currentForm.Rowset to decide which buttons to activate.
This way it works with every form in the app with no modifications
to the toolbar

Thanks for explaining!
I did not understand it initially because I could see that it's
Form-object (no "o" in the denominator as I'm used to) :-( :-(
Makes sense this to me.
Although being far closer, however, I still can not not really comment
on this as I have no insight on the basic architecture of your
applications. I'm just wondering a little bit why the object-reference
hanging at _app is *needed*. Couldn't the form(s) instead of registering
at _app talk to the toolbar directly?

To avoid misunderstandings: This is not meant as criticizing. What one
uses where is depending on many factors - especially in the not
formalized and flexible dBASE language. If it works for you, why
change it for what exists?

For future things perhaps Geoff's main points (especially encapsulation
and re-usability) and Lysander's considerations on the life-cycle of
object-references (which I share) might be food for thinking.

Thanks again
Rainald

[Frank J. Polan]

Rainald

On Mon, 1 Dec 2008 18:24:35 +0100, "Rainald" <***@gmx.de> wrote:

My toolbar is subclassed from the Toolbar class which has a built in
OnUpdate which is automatically & continuously available to accept
input. Therefore the Toolbar can respond immediately to any changes in
the current form,. No special coding is required in the form except
as noted below

Post by Rainald
Thanks for explaining!
I did not understand it initially because I could see that it's
Form-object (no "o" in the denominator as I'm used to) :-( :-(
Makes sense this to me.
Although being far closer, however, I still can not not really comment
on this as I have no insight on the basic architecture of your
applications. I'm just wondering a little bit why the object-reference
hanging at _app is *needed*. Couldn't the form(s) instead of registering
at _app talk to the toolbar directly?
To avoid misunderstandings: This is not meant as criticizing. What one
uses where is depending on many factors - especially in the not
formalized and flexible dBASE language. If it works for you, why
change it for what exists?
For future things perhaps Geoff's main points (especially encapsulation
and re-usability) and Lysander's considerations on the life-cycle of
object-references (which I share) might be food for thinking.

Reference Lysander's consideration, all my forms are based on a custom
class that among other things nulls the _app.currentForm reference on
the onLostFocus and onClose events. Therefore it never leaves an
orphaned object reference

There may be better ways of doing it but this has been working with no
problems for years

Thanks

Frank Polan

[Rainald]

Post by Frank J. Polan
Don't know what Glenn uses it for , but my "encapsulated" speedbar
works on the currentForm.rowset

Sorry I can not see what you are using in which way :-( :-(

Rainald

Post by Frank J. Polan

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Out of which reason?
What are you doing with that afterwards?
Rainald

Post by Glenn Johansen

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
an object to "group" items. For example, my application will
create: _app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all
of the reasons already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a
reason to change it
Jan

[Rainald]

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Just curios:
Out of which reason?
What are you doing with that afterwards?

Rainald

Post by Glenn Johansen

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
an object to "group" items. For example, my application will
create: _app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all of
the reasons already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a
reason to change it
Jan

[Glenn Johansen]

I use the form reference in system wide validation functions, and this goes
back to a long time ago and how I coded my routines. I would probly now send
the form object as a parameter when calling my valid events.

- glenn

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Out of which reason?
What are you doing with that afterwards?
Rainald

Post by Glenn Johansen

Post by Greg Neid
Hi Frank,
I use _app exactly as you describe, but with a few more
1) I never create a property directly under _app. I always create
an object to "group" items. For example, my application will
create: _app.user = new object()
_app.user.name = "Frank Polan"
_app.user.something = "Why not"
In a similar way, I have
_app.SystemParameters (overall application parameters)
_app.Display (size of display, fonts, color depth etc)
_app.License (licensing details about my application)
2) _app is never used to communicate between forms
In a few places, I was tempted to use _app to pass values between
forms - which would have resulted in a public variable. For all of
the reasons already discussed here, I don't do that.
I have not had any problems doing things this way and don't see a
reason to change it
Jan

[Rainald]

Post by Glenn Johansen

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Out of which reason?
What are you doing with that afterwards?

I use the form reference in system wide validation functions, and
this goes back to a long time ago and how I coded my routines. I
would probly now send the form object as a parameter when calling
my valid events.

Thanks a lot for your reply.
Understood.

And I agree with your conclusions.

Rainald

[Lysander]

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Thereby you are creating an additional reference on that form, and you
are hopefully taking care that this reference is dissolved and garbage
collected properly.

A lot of things have been written already in this thread, and I belong
to that group who is/was using PUBLICs whenever I felt that at the same
time they were handy and I would be able to not lose them out of sight.

But I never used publics or their "_app." incarnation to handle object
references, because if you do so, you really should take great care of
counting your references.

Orphaned references are the reason for a good crash more often than you
would probably guess.

[Lysander]

For all of the talk about crashes in dbase, I can honestly say that I have
not seen a single crash in my systems in over a year, and the ones before
that were my fault.

Yep!
Haven't seen any in 10 years, besides those caused by a mismatch between
Crystal Reports and a new printer driver, and those - of course - during
testing of new modules in design-mode

[Greg Hill]

Post by Lysander

For all of the talk about crashes in dbase, I can honestly say that I
have not seen a single crash in my systems in over a year, and the ones
before that were my fault.

Yep!
Haven't seen any in 10 years, besides those caused by a mismatch between
Crystal Reports and a new printer driver, and those - of course - during
testing of new modules in design-mode

Same with me except for a short while I was having trouble with the Crystal
Viewer (possibly with activex general), I think dBASE improved on activex.
I also worked around it by putting a crystal report in memory at the
beginning of my start up code, left it in memory and all my crystal problems
went away.

Greg Hill

[Glenn Johansen]

For all of the talk about crashes in dbase, I can honestly say that I have
not seen a single crash in my systems in over a year, and the ones before
that were my fault.

-glenn

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Thereby you are creating an additional reference on that form, and you are
hopefully taking care that this reference is dissolved and garbage
collected properly.
A lot of things have been written already in this thread, and I belong to
that group who is/was using PUBLICs whenever I felt that at the same time
they were handy and I would be able to not lose them out of sight.
But I never used publics or their "_app." incarnation to handle object
references, because if you do so, you really should take great care of
counting your references.
Orphaned references are the reason for a good crash more often than you
would probably guess.

[Glenn Johansen]

I set it in the ongotfocus and null it out in the on lostfocus events of the
form.

Post by Glenn Johansen
and I store the current form that has focus.
_app.currentform

Thereby you are creating an additional reference on that form, and you are
hopefully taking care that this reference is dissolved and garbage
collected properly.
A lot of things have been written already in this thread, and I belong to
that group who is/was using PUBLICs whenever I felt that at the same time
they were handy and I would be able to not lose them out of sight.
But I never used publics or their "_app." incarnation to handle object
references, because if you do so, you really should take great care of
counting your references.
Orphaned references are the reason for a good crash more often than you
would probably guess.