Topic: Lisp how to question

[One Shot]

I have an interior round column and a interior square column that I use a great deal for interior elevation.  How do you write a lisp that would insert this column by picking the top point and the bottom point?  Also to be able indicate what width you want it.

Example:  You pick the Ceiling and then pick the Floor and to indicate the width.

I can send the block of the column to you if you request it.

Thank you,

[Mark]

Are you trying to scale the block by picking the ceiling and floor? Or just fill in some attributes based on the distance of the picked points?

We really need to work out some pseudo code before we delve into the code.

[One Shot]

Are you trying to scale the block by picking the ceiling and floor? Or just fill in some attributes based on the distance of the picked points?

We really need to work out some pseudo code before we delve into the code.

I am trying to scale the block by picking the Ceiling and the Floor.

[Mark]

Ok, so the pseudo code might look something like this.

present user with choice of two blocks. (default to round)
store block name in variable 'blk_name'.

prompt user for two points, retrieve distance between those points
and use as Y scale factor. variable 'blk_y

prompt user for column width. use for X scale factor. variable 'blk_x.

prompt user for insertion point. variable 'blk_insert'

use 'command' for block insertion.

command "insert" <blk_name> <blk_insert> blk_x blk_y 0.0

sound about right?

[CAB]

This code is more like pseudo code, that is bare bones with no error checking.
Create a DWG with a column drawn in it. Lower left of column is 0,0
Column width is one unit and height is 3 units. I actually drew a column full size
& then scaled it down to one unit wide. Then stretched it to 3 units high.
I named the file COLUMN-01.dwg
This routine will insert the column to your entered dimensions.
You may want to use a different insert point and different beginning size for the
block but the process is still the same.
I'm sure Mark has some more advice for you. And better looking code for sure.
But this may get you started.

Code: [Select]

(defun c:column (/ col len pt1 wdth y-scale)
  ;;  in this example Block Column-01 has a width of one unit and
  ;;  a height of 3 units

  ;; uncomment the next line & delete the override
  ;(setq COL (getstring "\nEnter style of column to be used: "))
  (setq col "COLUMN-01") ; override for testing

  (setq wdth (getdist "\n\nEnter width of column in inches: "))

  (setq pt1 (getpoint "\nPick Bottom Left of Column : "))

  (setq len (getdist pt1 "\nPick or Enter Length of Column : "))
  ;;  calc y scale based on block is 3 units high
  (setq y-scale (/ len 3.0))
  (command "-INSERT" col pt1 wdth y-scale 0.0)
  (princ)
)

PS if you want to pick the top of column first, you can calc the bottom insert point or
just draw you block column dwg with the upper left at 0,0

[JohnK]

This brings up a good point. I think i need to post my "symbology and Syntax" ideas for pseudo code.

In my opinion, pseudo code is one of the most important steps. I've designed whole applications with pseudo code and ive "written the code" on my way home in the car. People forget (or dont know) that the code is the easy part. Its the theory that is the real kicker.

Ive seen pseudo code that takes the form of both of what Mark wrote (a script, or a TODO list) and of what CAB wrote. (A very basic coded app.). Ive found that a structured Pseudo code app is way easier to write out in code. (Sub procedures and variables are harder to see otherwise.)

I was actually taking on a small project at work (Gawd forbid i actually get an opportunity to work on it anytime soon!?) but i think i will share my "initial set up" for my project tomorrow.

[MP]

I've seen many variants of pseudo code but I like ones that are concise and based on plain english, otherwise I might as well right code. Admittedly, getting to be old fert stuck in me ways.

[SMadsen]

All depends. Anyone ever used process diagrams with true/false routes between the rhombs and squares and rounded boxes kinda symbols? Reminds me of school projects before punching the program and tossing it into the punchcard reader  

[Mark]

All depends. Anyone ever used process diagrams with true/false routes between the rhombs and squares and rounded boxes kinda symbols?

I probably would if I ever wrote an application large enough to justify it. <g>

[MP]

All depends. Anyone ever used process diagrams with true/false routes between the rhombs and squares and rounded boxes kinda symbols? Reminds me of school projects before punching the program and tossing it into the punchcard reader  :)

Yep, and used UML etc. It really depends on the scale of the project and how many hands are in it. UML modeling can be the way to go, I did a fair amount of it at University. But like I said, it's all about scale. Most AutoCAD applications can be described by a very good narrative, some of it plain english, some of it pseudo code, UML et al being overkill (IMO).

For example, it is not uncommon for me to write an entire application in comments, send it round to a couple folks for review, and then once we have consensus, fill in the code between the comments. When I'm done the source code is already commented; sweet. I think I sent a sample of this to John way back, perhaps I can find it and post it here.

The bottom line is that while we may not all agree on the type of modeling, psuedo code etc. I believe we all agree there is need to communicate the intent of the programming, "What is this thing solving, and how are we going to do it?". No question, it's a must.

[CAB]

I used to have a routine that would create a "flow diagram" or "program tree" form
the already written code. It was for FoxBase a version of dBase. I used it often
when working with large programs. Anything like that for lisp?

On routines like this one I usually fly in writing code as the pseudo code is in my head.
On larger routine the pseudo code won't fit so I put it on paper. Usually scribbled notes
in a leaner fashion. Often  using a separate sheet for subroutines because I like to keep
the main routine as simple as I can. I usually create a subroutine when the function is
called more that a few times or the sub itself is more than a few lines long.

Like my PLotTabs.lsp the Main code is about 20 lines & the rest of the 700+ lines are
subroutines.

[CAB]

The bottom line is that while we may not all agree on the type of modeling, psuedo code etc. I believe we all agree there is need to communicate the intent of the programming, "What is this thing solving, and how are we going to do it?". No question, it's a must.

Well Said.

[nivuahc]

When I first started programming (BASIC), I used to draw flow charts with a template and a pencil.

Usually, half-way through the flowchart, I would change my mind about writing the code at all.

I quit drawing flowcharts.

[CAB]

One Shot
We didn't hear from you again.
Did you solve your problem?

[One Shot]

I have been away from the office all week doing field visits.  Have not read this since I posted this question.  So to answer your question.  Not yet.

Thank you for asking.

Brad