thanks --on more

is there a way to load the style in the .lin file.

 

Example:

(defun mkstyle ( Font_name Font_file /)
(entmake
(list
(cons 0 "STYLE")
(cons 100 "AcDbSymbolTableRecord")
(cons 100 "AcDbTextStyleTableRecord")
(cons 2 Font_name)
(cons 70 0)
(cons 40 0.0)
(cons 41 0.8)
(cons 50 0.0)
(cons 71 0)
(cons 42 2.5)
(cons 3 Font_file)
(cons 4 "")
)
)
(princ)
)

--

AUTODESK
Authorized Developer
www.Cadentity.com
MASi

 

Nope,
You load the style from .shx.
You 'refer' to it in the .lin
Sorry.
You could insert a 'block' with all kinds of 'styles' already loaded, and they will all load when inserted. Block does not 'have' to have any graphic elements (e.g. lines, circles..), just the 'preloaded' text styles'.

Bob

 

Shame on you Rudy.
Thought we didn't want to use the entmake stuff.
Bob

 

? Who's we Tonto?

And why wouldn't you use the entmake stuff?

If you're referring to VL functions, then subtitute.

Remember, my post mentioned Example, not do it this way.

 

Sorry,
I was thinking about NG threads..from Tony.
:>)
Your suggestion will work just fine.
Be aware of using entmake..search NG for 'entmake' and read up.
Sorry again.
Bob

 

Be aware of what?



I haven't had any problems other than using it with vl functions, and we've
already found a work around, thanks to Luis E, and other contributors.



2004 fixes any additional problems 'entmake' may have had.



On the other hand you can use 'entmake' for just about anything, but
somethings can only be set via the VL functions.
--

AUTODESK
Authorized Developer
www.Cadentity.com
MASi

 

Found part of the thread.

NG : Tony T, Jan 25:

Autodesk has already made it clear that they're not going
continue supporting the (entxxxx) style functions for accessing
and modifying entity data. In fact, newer releases of some
vertical products do not even support it, and the only way to
access the custom objects in those applications is via their
ActiveX interfaces.

While you can continue to do relatively simple programming
with that style of coding, it is obsolete and certainly does
not have any future. Considering how cryptic DXF codes are,
I can't see why anyone would want to program that way any
longer, given the ActiveX API, but in LISP, the syntax is a
bit convoluted, and you have to write a lot more code (the
advantage is that it is more explicit and therefore makes the
intent of the code much clearer, at the expense of brevity).

ActiveX is fine if you use VBA or another imperative language
with a rational OOP syntax, but for LISP it is simply not my
preferred way to code.

The point to the comment about the entxxxx style of LISP
coding, is that someone was using it to "copy" entities,
but didn't realize that it was not really doing that, and
hence, could have undesireable effects in some circumstances.

That thread is what I'm referring to.
You can do what you like.
Bob

 

Thank God I'm moving into .NET