Friday, March 30, 2007

Solid gold

Ok I haven't posted in too long and this one is going to be really short, but I have some really fun plans along the lines of a function key parser, editor, etc. that will really push into the python dictionary data type.

For now though let me pass along huge kudos to the team at Cardinal. I often have thoughts of the guys slaving away in the salt mines at the Vr Development lab. Poorly used and un-appreciated for the efforts that spring forth. However in the latest patch versions (usual disclaimers about beta software, or anything that isn't in official full release, blah..blah..) there are a couple of nuggets of pure gold. One is attaching in fly-line, granted this doesn't have anything to do with python, but along with things like all the different snap options, overloading (I better stop before I get carried away) attaching a fly-line is one of those things that will make me pause and think "wow, I love this stuff". The python related gold nugget is Ws.IdEnt() which allows the user to just start a generic ID routine then select anything on the screen, or cycle through entity types. This is the same ID that is used for fasdel and others like it. Check it out on the python help pages, it is absolutely too cool.

I'll also toss in a little utility that I use to save the current layer display status. Disclaimer here is that it only works with 3.2 and above because before that PyVrLayer had it's own module. It could be modified to work like that, but this version doesn't.

Layer = VrLayer ()
Gui=PyVrGui()
# Initialize Vr objects to be used.
parfile=open('c:/vr/hostdir/save_lay_stat.par','w')
# Open a parameter file to save the layer status in. 'w' is write mode.
for laynum in range(1000):
..parfile.write("%d %d\n"%(laynum,Layer.Stat(laynum)))
Gui.DspMsg0('Layer state saved')
# I'm only going to save the status of the first 1000 layers, I rarely use any others.
# Then write the Stat() or current status along with the layer number.
parfile.close()
# Always close files when done. Python is smart this way, but it's good practice.



Friday, March 02, 2007

A touch of class

You can do an amazing amount of good with VrPython without knowing anything about Object Oriented Programming (OOP). For that matter most, or at least many things you can do without even knowing much about Python. In my opinion though, knowing more is always better than knowing less. Let's talk a little about how I understand OOP working out in Vr. To begin with there is a very good explanation of the basic concepts on Wikipedia. I could make up my own example of the biggies like class, object, inheritance but they do such a good job there that I'll just trust anyone who needs a basic understanding to read it (3-5 minutes tops).
Let's look at a line. In VrPython there is a class called PyVrLine. Any object which is created from that class has many attributes, characteristics, data (whatever you want to call it) which describes it's state. Examples of these attributes (the word I'll stick with) are it's layer, graphic pointer, width, coordinate list and so on. A line also has many methods, or functions it can perform based primarily on it's current state. When ever I create an individual object or instance of that class, I have access to all the attributes and methods that go with it. In Vr the individual object is created with the command
Line=PyVrLine()
I have often wondered if I am confusing things by using the word "Line" as the name of the particular object. Sure it is descriptive and relevant, but for example purposes it needs to be clear that I could use any name for the object being created which is of the class PyVrLine. It is just an identifier of the unique entity I'll be using just like Dennis is just a name used to identify this particular object of the Human class.

In any case, whatever we call a particular instance, once we have a PyVrLine(), the fun can begin. On of the most useful functions when starting off is Id(). Once there is a PyVrLine object, Id() will use the function built into it to bring up a familiar set of identification menu keys and wait for the user to click button #1. If the click meets all the criteria to find a line Id() will not only return the line number of the line it found, but will populate the PyVrLine object with all the attributes of the identified entity. It does the exact same thing as Load() but allows for visual identification in the current workspace. Once the PyVrLine object is loaded (or I suppose created from scratch with default values) the whole host of methods that can get, set, or compute information based on the current state become available.
The key is that a Vr object can't just be looked at even as a complex collection of data, but also as the family of functions that allow user interaction with it. This frees the developers to grant access to the power of the internal magic in a secure manner, and the user from having to understand what is going on (or having to re-invent the wheel for typical data interaction).
Ok I'm rambling and really need to bring this to a close. Besides the fact that OOP is really cool, and it helps to have a simple understanding of how it works out in Vr, what is the point? Is there any reason that a person might want to learn to use classes in everyday programming? I very rarely do, and most of the true object oriented modules I've written were done because I wanted to give it a try, but here is an example. I have a module which contains an angle class. An object created from this class of course stores the value of the angle it represents, but it also contains methods that allow it to represent itself in radians, degree-minutes-seconds, decimal degrees, bearings with quadrant, any of the above in varying text formats along with an overloaded repr(). Along with this there are methods that allow for conversion between the varying systems. All these things are easy enough to do on the fly, but a consistent interface and descriptive names make programs that use the class easier to read, and playing with basics like this makes understanding modules written by really intelligent programmers a bit easier to follow.

For anyone interested in trying VrPython for the first time or if you are early in the game, I suggest going to the earliest posts and working forward. I use VrPython every day for many wonderful things, needless to say it will change and could potentially damage a file. Any risk associated with using VrPython or any code or scripts mentioned here lies solely with the end user.

The "Personal VrPython page" in the link section will contain many code examples and an organized table of contents to this blog in a fairly un-attractive (for now) form.