Coding practices - Global Variables...

When I tried using the vl-Propagate 'blackboard' function to expose code to
all newly opened drawings, I ran into the problem that vl-Propagate doesn't
execute until after s::startup.

Dan

 

Tony:

After re-reading my post, I realize that I should have said "I at least
completely declare and define them in the same *PROJECT* as the code that
relies on them." That is, I prefer to define new globals for every project,
even if they have the same function as a global in an unrelated project.
Modularity is, in a way, what I was referring to. I prefer well defined
project boundaries, and even well defined sub-project boundaries (like
files). Having well defined boundaries makes entire projects, and
subprojects (files) transportable with minimal muss and fuss.

In practice I also tend to segregate things in many files. But, for
example, any "global" that is only used in one file would always go into the
same file as the code using it. Any global that is used exclusively by one
subproject would go into a separate file, but a file that is also exclusive
to that subproject. If I start reusing the same code in different projects,
at some point it reaches critical mass and I put that code into a new unit
inside a common library that all projects can use. The code in the common
library is then neatly segregated and insulated so there are, again, clean
boundaries between sub-projects of the common library.

I am anal about organizing code on the one hand, but on the other hand I
generally spew a mess of code that seems to defy organization. Then, at
some point I find the mess unwieldy and I start reorganizing. Then I throw
more code into the pot, then after a while I reorganize again. Someone
watching over my shoulder would surely see no rhyme or reason to my style,
but amid the apparent chaos there is always a goal of keeping clear
boundaries with minimal crossover (admittedly sometimes at the expense of
some duplication -- which I also abhor).

Sometimes I wonder whether all the time spent organizing code really
serves useful a purpose. But, I only need to open some of my projects from
the 1990s to dispel that notion.

 

Bobby:

I will probably end up going. I've been waffling about going at all, but
I'll probably end up going for at least a few days. I guess I should start
thinking about plane tix... <

 

David - I generally try to have a single entry point for
initializing an application (in this sense, you can think
of the ongoing customization you do for yourself in its
entirety as an 'application').

Regarding .MNL files, there's to reasons to use them:

1. To load code that an associated .MNU/MNS is
dependent on.

2. As a better way to load code (in preference to
the startup suite, which loads some things twice
depending on how you open a drawing).

So, even when I use an .MNL file, it usually contains
only a single expression:

(load "init.lsp")

Where "init.lsp" is the primary LISP initialization file
that leads to the loading of all other files. When you
have LISP that executes directly (as opposed to being
nested in a function body), then its important that
any code that the directly-executing code is dependent
on is loaded first.

My use of the blackboard, is for the purpose of
having variables that have 'application-level' scope.

Remembering that every document contains what is
in essence its own LISP interpreter, and variable
namespace, the values of variables in each document
namespace are distinct and invisible from any other
document's namespace. Hence, if you do something
like this in each document:

(setq MyComObject
(vla-getInterfaceObject
(vlax-get-acad-object)
"Some.ComObject"
)
)

You will be creating multiple instances of the requested
COM object (assuming it is not a singleton), one for each
open document in AutoCAD.

For some applications, I don't want multiple instances of
a COM object (one for each open Document), but rather,
I want only one instance of the COM object, which I can use
from any open document. The only way to do that, is
via the blackboard, which can hold a variable assigned to
a vla-object, which can be referenced from any open
document.

 

Tony,

Well, sounds like the .mnl setup I've been using is still pretty much inline
with what you say. (I don't use any S::STARTUP functions, either, btw)

The only things I've got in the Startup Suite are DosLib, and your FlatLand,
AcadX, and a DynaMode initiator (seemed to be the only way I could get it to
work with multiple drawings). The rest of my custom routines, 3rd party
apps, etc are handled by loads/autoloads via the .mnl, and other Menuloaded
applications in my Profile.

Like I said, things've been pretty stable - just was wondering if progress
on other fronts made it feasible to make some changes.

Thanks very much for your kind explanation.

Best regards,
David Kozina

 

There are cases where you cannot have locals, say (in my case)

I use a single name for some of my default entries based on companies
standards.

e.g.

1

Say I have a client called "LACOMA" (made up name)

The default dimstyle name I use is "LACOMA"

Default text style I use is "LACOMA"

Menu name I use is "LACOMA"

Instead of changing this value all over the places, I use a global variable
that holds default names, DEF_NME and loads with my application. So I will
have deal with a single fas/vlx file to keep my globals and not to have
floated throughout my application.

I do keep globals in one module in my VB applications too. Here are more
cases for global symbols use.



2

Default font for default text style I keep it in global variable, because
this name is used in multiple places too



3

The ratio between LTSCALE and DIMSCALE I use 0.25, LTS_SCL

This number I use in number of places, so I can control this with a single
variable



4

Several file type extensions, like ".dwg", ".dxf", ".doc" etc. to DWG, DXF,
DOC etc.



5

Number of directories and their full paths based on installation location



6

Most common registry keys like HKEY_CLASSES_ROOT for "HKEY_CLASSES_ROOT"

etc.



7, 8, ... etc.



Some variables are set with <setq> statement some of them are created
dynamically, during the application load or installation



These types of variables I consider to keep in global names instead of
local. I could save them all in the registry and read them as I needed but I
found "faster" to retrieve these values from global names.



And again, all lisp functions, existing or we make, are global symbols..

(defun AddOne (NUM)

(setq NUM (1+ NUM))

)

So, the symbol AddOne is defined as a global symbol.

programs because of it... but it's better...

i did it with Xdata attachment... it's very useful to keep those particular
configurations in every drawing.