custom pull down to activate lisp routine

i'm currently making a pull down for all my blocks and starting thinking to myself why not add all my custom lisp routines as well. how would i code that?

for instance how could i make it activate this lisp through my menu

(defun C:QD ()
(command "DIST" "NEA" pause "PER")
)


here is a portion of the menu

***MENUGROUP=NK

***POP1
[NK]


[->Lisp]




thanks all!!!

 

[->Lisp]
  [command 1]^C^CQD
  [<-command 2]^C^C(function name)
if you define your fuction as a comand (defun c:qd ())
you can use QD
If you define your function as (defun QD ()) call it using
(QD)

also lisp code can be used
Ex
[mid+mid/2]'cal;(mid+mid)/2

notice the lack of ^C^C, these are are cancels that will quit any current command

 

Assumptions:
lisp filename = qd.lsp and is in a support folder.
function = (defun C:qd ()....
In Menu:
[->Lisp]
[Load and run QD]^c^c(if (not C:QD)(load "qd.lsp")) QD;
[Next lisp ]^c^c.......
[<- Last Lisp]^c^c.......

Bob

 

Just like this:

[fillns,fillet near side]^c^c-insert *fillns \;;

The above is for images but can be customized for, say a pop12 or pop13as below:

[fillet near side]^c^c-insert *fillns \;;

 

For lsp routines:

[Ellipse Centerlines]^c^c^p(if (not cle)(load "cle"));cle

 

Bob, I dislike putting the "load and run" business in a menu macro, with the "if" test. Once upon a time it was necessary, but the whole point of mnl files is to allow you to get rid of all that inline lisp, which (as in this case, if it's carried to the logical conclusion) tends to be highly repetitive and a major pain to maintain. You can put a series of autoload statements in the mnl file, and then the menu macro doesn't need to do anything but call the function.

Example, using the same assumptions, (c:QD) is in QD.LSP on the search path...

in <menuname>.mnl,
(autroload "qd.lsp" '("qd"))

In <menuname>.mns:
[->Lisp]
[QuickDist - QD]^c^cqd;
[Next lisp ]^c^c.......
[<- Last Lisp]^c^c.......

Note, I'm guessing at the meaning of QD, but I would definitely put a meaningful label on the menu item, not just a two-letter command alias. IMHO the pulldown menu approach is going to be a lot slower than the keynoard equivalent. The major thing about 1- or 2-letter keyboard macros is speed. The only value I'd see in putting these on a pulldown is that they'd be easier to find and learn for a newcomer to the firm. They could at least find the routines this way until they learned the keyboard shortcuts.

 

And, if it is not in the .mnl ?
.....
Bob

 

And, this was the question:
(defun C:QD ()
(command "DIST" "NEA" pause "PER")
)
<<
So, did I not answer the question ?
I agree that learning the 2 key stroke is good, and
the menu 'label' should be more in line with what will
happen as a result of picking the item.
The IF...just insulates against the command (not) being
loaded, and will just fire up the command (if) loaded.
No problem.
I disagree with placing most lisp in the .mnl file..
you 'must' pass this file along with an application..and if
you don't...no lisp. If you get my drift.
Bob

 

Why not:

[Quick Distance]^c^c^p(if (not qd)(load "qd"));qd

 

Perfect.
Bob

 

I don't see that "activating through my menu" would disqualify using the file which is automatically loaded when the menu is loaded. I view the mns menu source file and mnl menu lisp file as both being components of "the menu."

The "what if" with regard to the mnl strikes me as strangely hypothetical and a bit paranoid. Sure, the mnl file needs to accompany the compiled mnc in order for everything to work. So does the mnr, and any and all lisps that are referenced by the menu, and any and all blocks that are inserted from it, and any and all "library" functions that your lisps depend upon, and so on. And your paths are going to need to be set to contain all these things.

Point being, the mns file doesn't stand alone, it's part of a system. If you don't "pass along" all the other stuff, nothing's gonna work. Each one of them will trigger a specific kind of error if absent.

What if the external lisp file isn't available on the path? The "if" test doesn't insulate against that, and the load will error out if the lisp is missing. Get my drift?

Our entire suite of customizations is initialized by an mnl associated with a custom partial menu. It loads the few essential lisps that make everything else work, including a big file of "library" routines which all our functions (and all our menu macros) depend upon, and one "loader-upper" lisp which autoloads all our freestanding lisps. We've had a couple dozen folks working that way since R14, quite a few thousands of Acad sessions, and we've never seen the mnl file spontaneously disappear and cause everything to fail. In other words, in my own experience, this is a perfectly trustworthy way of doing things.

In our case, the mnl is particularly critical, and it would be immediately obvious if it failed -- absolutely none of our stuff would function. In fact, none of the other lisps would even load. This is by design. I run a copyright-protection encrypted lisp first, which won't let anything else work unless certain conditions are true, and every lisp references routines contained within it. This is to prevent our stuff from being "shared" outside the office. If you try to load any of our lisp routines outside of our setup, you'll get a stern copyright notice and nothing else -- the load will abort.

Bottom line, if depending on the presence of an mnl were a risky business, as you seem to think, I would have abandoned the approach a few years ago. But in fact it works fine.

 

Yes, Walter is actually perfect. Every good lisp programmer should put a (vmon) statement in his acad.lsp, to ensure that virtual memory paging is enabled, in case you have installed "extended memory" beyond 640KB of RAM. This has been discussed in depth, search Google on "vmon" for details.

 

Yes, Walter is actually perfect. Every good lisp programmer should put a (vmon) statement in his acad.lsp, to ensure that virtual memory paging is enabled, in case you have installed "extended memory" beyond 640KB of RAM. This has been discussed in depth, search Google on "vmon" for details.