MEDICIONES y PRESUPUSTO ( II )

En la entrada del día anterior, se ha desarrollado una exposición general sobre la elaboración de mediciones y presupuestos en los proyectos de arquitectura, su trascendencia y algunos aspectos prácticos sobre su elaboración en los últimos años dentro del ámbito de este país.

En los últimos párrafos se mencionaba el sistema de módulos que se ha utilizado por los colegios de arquitectos, la incidencia que había tenido durante su vigencia, y la desregulación que han supuesto los cambios legislativos, y la aparición de ciertas “incertidumbres” o dudas sobre el “rigor” de los presupuestos  que se incluyen en algunos proyectos técnicos de iniciativa estrictamente privada.

El sistema Medición-Presupuesto

Una de las características destacables del documento de mediciones y presupuesto, es la “ingente” cantidad de datos numéricos que puede acarrear, y en consecuencia la probabilidad de generar errores de todo tipo, y las dificultades para establecer sistemas de control “riguroso” sobre su integridad. Esta cantidad de datos numéricos que incluye el documento es lógicamente proporcional a la magnitud o volumen del proyecto, y en el caso de obras singulares o de cierto tamaño puede llegar a generar volúmenes de varios cientos de páginas de texto mecanografiado. No obstante en este sentido cabe mencionar las diferencias tradicionales entre los proyectos de “arquitectura” y los de “obra civil” que a su vez ilustran, amplían y refuerzan diferencias de criterios entre “arquitectos” e “ingenieros de caminos”.

En el caso de los ingenieros de caminos y la obra civil, hay que destacar que tanto los proyectos técnicos como el ejercicio profesional, siempre han tenido una cierta convergencia con muchos elementos comunes en el sector de la construcción, y como ejemplo  es frecuente que las empresas constructoras operen tanto en “obra civil” como en “edificación”, los laboratorios de control de calidad operan indistintamente en ambos sectores, y de hecho si se examinan con detenimiento los procesos de “construcción”, se puede apreciar que la relación de “unidades de obra”, que intervienen en muchos casos son las mismas, (movimiento de tierras, cimentaciones, estructuras de hormigón y acero, pavimentaciones, redes e instalaciones de saneamiento o desagües, abastecimiento o fontanería, iluminación y alumbrado público, electricidad .. etc). De hecho las bases de precios y unidades de obra, o los programas informáticos suelen emplearse indistintamente en ambos sectores.

Una característica singular que sin embargo diferencia claramente a ambos, es la magnitud relativa en el momento de cuantificar cada proyecto. Como ejemplo cabe mencionar que en el caso de una “vivienda unifamiliar”, el número de unidades de obra diferentes que pueden ser necesarias para completar su construcción, puede llegar fácilmente a las doscientas, aunque difícilmente se va a totalizar un importe acumulado de más de ciento cincuenta o doscientos mil euros. Sin embargo en un pequeño proyecto de obra civil, como puede ser un tramo de carretera sencilla, probablemente el número de “unidades de obra” necesarias no supere el centenar, pero sin embargo la cuantía acumulada difícilmente bajará de los cinco o diez millones de euros, lo que representa que para una “unidad de obra” similar en ambos proyectos, se multiplica su incidencia o valor relativo, por un factor cien o doscientas veces mayor.

Esta diferencia cuantitativa entre las magnitudes relativas de las unidades de obra habituales en ambos proyectos, además de otra diferencia frecuente, como es el hecho de que los proyectos de obra civil sean normalmente de iniciativa “pública”, y los de edificación en su mayoría de “iniciativa privada”, acaban motivando que se aborde esta parte del proyecto con criterios claramente diferenciados.

Por un lado en el caso de los ingenieros de caminos y la obra civil, el criterio habitual, profundiza mediante un “análisis” más exhaustivo de los datos, para descomponer los elementos de cada unidad de obra (descomposición de precios .. ) cruzando valores comunes entre distintas unidades, que pueden poner de manifiesto incoherencias del conjunto, y añadir algunas redundancias que contribuyen a poner de manifiesto cierto tipo de errores, (cuadros de precios en letra y número .. etc. ). Esto lógicamente contribuye a incrementar notablemente el volumen de datos numéricos y también la carga de trabajo y esfuerzo sobre la elaboración del proyecto, aunque dado que la magnitud de estos, es bastante mayor que en el caso de la edificación y su carga de trabajo en aquellos aspectos como la originalidad, la innovación, y el diseño o la estética son sustancialmente menores, hacen que esa “hipertrofia” de datos numéricos dentro del presupuesto también se acabe convirtiendo en un factor de diferenciación que llega a utilizarse como respaldo de su propio “prestigio profesional”. 

                                               

Por el contrario en el ámbito de la arquitectura, por un lado la “reglamentación” de tipo administrativo es más relajada, ya que suele operar en el ámbito de la iniciativa privada, y por otro lado el “valor propio” del trabajo se tiende a ubicar en la vertiente gráfica, dando mucha más importancia a los factores subjetivos y discrecionales, como el diseño estético, la innovación, la originalidad etc. que están más vinculados a la identidad y al prestigio personal de cada arquitecto.

En este sentido el documento del presupuesto, se aborda inicialmente de forma similar, elaborando una “medición” exhaustiva, que al igual que en la obra civil, se compone de una lista completa de unidades de obra, junto con la recopilación sistemática de datos numéricos necesarios para calcular sus magnitudes en el proyecto. No obstante a la hora de establecer los precios para esas unidades de obra, en lugar de profundizar en la elaboración de los precios a través de un “análisis” exhaustivo que incrementa desaforadamente el volumen de datos numéricos, se suele recurrir a través de cierta capacidad de “síntesis”, a tomar referencias “externas y objetivas”, que permitan aproximar o acotar un presupuesto final, mediante experiencias recopiladas con tipologías de casos similares.

Esa recopilación de referencias y tipologías es lo que en última instancia constituyen y representan los sistemas de “módulos” empleados tradicionalmente en los colegios de arquitectos, que a su vez se convertían en “referencia objetiva” a través de esa estructura sindicada de la profesión del arquitecto.

Consideraciones sobre los módulos.

En primer lugar hay que mencionar que la capacidad de regulación que pudieran ejercer los colegios de arquitectos a través de los sistemas de “módulos” han sido suprimidos completamente por la legislación general, en una primera etapa con la eliminación de las “tarifas de honorarios”, y finalmente con la aplicación de la conocida como Ley Ómnibus, que establece una determinada transposición de la legislación comunitaria.

En este sentido, cabe decir que los argumentos para la eliminación de los sistemas de “módulos”, han sido derivados de la “competencia” ya que supuestamente la capacidad de regulación que ejercían los “colegios de arquitectos”, generaba una falta de competencia entre los profesionales y consecuentemente un “encarecimiento” artificial de los servicios que desempeñaban.

Con independencia de que el razonamiento pueda parecer correcto a primera vista, la realidad es sustancialmente diferente, ya que la competencia para elegir un “arquitecto” concreto en detrimento de otro, casi nunca se ha dirimido por la repercusión económica del importe de sus “honorarios”. La competencia entre profesionales se ha ido desarrollando por otras muchas cuestiones y factores propios de la complejidad del trabajo, cuya valoración de “calidad” tiene un marcado carácter “subjetivo” a diferencia de cualquier otra ingeniería. Como factores de competencia entre arquitectos, cabe citar la “notoriedad”, la “experiencia”, una “capacidad” contrastada en trabajos similares, o bien una “sintonía personal” con el cliente, que ayuda a trasladar al proyecto, las inquietudes, preocupaciones o ansiedades que todo “promotor” tiene cuando se inicia una nueva “empresa”.

Los sistemas de módulos utilizados normalmente por los colegios de arquitectos, consisten en aplicar un “valor medio” de referencia sobre la superficie construida del edificio, que es la magnitud más característica y proporcional de su coste, corrigiendo y ajustando ese valor medio con un repertorio más o menos amplio de circunstancias fácilmente identificables a primera vista, que repercuten el coste de la construcción, como pueden ser numero de fachadas, los tipos de acabados, tipologías constructivas (naves de acero, estructura de hormigón armado, .. ) etc.

Estos sistemas permiten un control relativamente fácil mediante algún tipo de formulario donde figure un resumen de los datos más característicos del edificio proyectado o también establecer avances o aproximaciones del coste de construcción en las fases más iniciales del proyecto, ayudando a descartar o adoptar distintas soluciones o alternativas.

Una de las ventajas del sistema es su simplicidad, ya que manejando las superficies construidas de cada tipología y unos pocos datos numéricos, se puede obtener una aproximación razonable de su coste o “presupuesto”, que permite adoptar decisiones y/o criterios en la fase de diseño, sin necesidad de completar la larga elaboración del presupuesto. Lógicamente en los proyectos de ingeniería civil, también se emplean sistemas de “índices” con un objetivo similar, pero mucho más desligados de la elaboración final del presupuesto y desde luego sin el carácter “general y objetivo” que aporta una entidad ajena al propio estudio u oficina técnica.

MEDICIONES y PRESUPUSTO ( I )

Una vez concluido el tema dedicado a la personalización de AutoCAD, parece oportuno hacer un cambio, para refrescar ligeramente la saturación del tema anterior. El nuevo tema elegido es la elaboración de “mediciones y presupuestos” en los proyectos de arquitectura, que constituye una cuestión de cierta trascendencia, a la que sin embargo entre los profesionales “arquitectos”, no siempre se le presta toda la atención necesaria.

Los elementos del proyecto

Para situar el tema en su contexto, cabe recordar aquella división clásica de los documentos de cualquier proyecto técnico: (Memoria, Planos, Pliego de Condiciones y Medición-Presupuesto.) Esas cuatro partes responden a una estructura conceptual que podría configurar cualquier proyecto, y que se puede definir como sigue:

La Memoria: Es una parte escrita donde se identifican, describen y explican todo tipo de requisitos, características y circunstancias relevantes del objeto que se proyecta. El documento debe incluir tanto la “descripción” completa del objeto en si mismo, como de los “usos” previstos o asignados globalmente o en cada una de sus partes y los “requisitos” de todo tipo, ya sean criterios de diseño, iniciativas discrecionales del promotor, o bien imposiciones legales y reglamentarias, incluyendo la justificación de su cumplimiento.

Los Planos: Incluyen toda la parte gráfica donde se identifican y especifican tanto la situación y emplazamiento del objeto como sus características dimensionales, geométricas y de aspecto, así como todas las especificaciones gráficas necesarias para concretar rigurosamente todos sus elementos y componentes. El contenido y configuración de los planos debe ser tal, que puedan permitir la construcción del objeto con fidelidad al proyecto, pero bajo la dirección de una persona diferente del autor, aunque con el mismo nivel técnico.

El Pliego de Condiciones: Esta es una parte escrita del documento en la que se incluyen las condiciones y requisitos de toda índole, a las que se debe ajustar la “ejecución” o construcción del objeto que se proyecta. Este documento incluye desde atribuciones de los técnicos, responsabilidades del promotor, constructor o de otros agentes, condiciones de rescisión de contratos, fianzas, penalizaciones por incumplimiento, requisitos de control, comprobaciones, ensayos etc, y también  las “prescripciones técnicas”, sobre “condiciones de ejecución” de todas las unidades de obra.

                                                                         

La Medición-Presupuesto: Este es también un documento escrito, en el que se describen y relacionan sistemáticamente todas las “unidades de obra” que contiene un proyecto. Cada una de ellas se identifica mediante una descripción técnica, una numeración correlativa estructurada en capítulos y una “dimensión” o unidad que permite “medir” o cuantificar la magnitud acumulada en todo el proyecto. Además de esto se valora su importe de ejecución, mediante la asignación de un “precio unitario” que multiplicado por la magnitud total, permite determinar el coste de ejecución del proyecto.

Obviamente el hecho de conocer previamente, el importe que puede costar la construcción de un edificio o cualquier objeto proyectado, con la trascendencia que ello supone para respaldar o avalar todo tipo de decisiones, tanto de iniciativa empresarial y económica, como de control administrativo,  justifican en gran medida la utilidad y el esfuerzo que suponen elaborar cualquier proyecto de forma rigurosa, prestando una atención singular a esta parte del documento.

Mediciones y Presupuestos

Esta parte del proyecto se compone a su vez de dos elementos diferenciados. Por un lado la determinación de las magnitudes de cada unidad de obra, y por otro lado la asignación de los precios unitarios de cada una.

La primera parte es lo que comúnmente se identifica como “Mediciones” del proyecto, y se elabora como un listado sistemático ordenado por capítulos, donde se va identificando cada unidad de obra, y a continuación dentro de ella se anotan en una lista, con tantas líneas como sea necesario, los datos numéricos de dimensiones parciales que van formando los elementos o partes de cada unidad, y que en rigor deberían ser perfectamente identificables dentro de los  planos, mediante sus “acotaciones” sin necesidad de efectuar ninguna medición directa.

Las líneas de medición se pueden completar con un pequeño texto aclaratorio que contribuye a identificar el elemento que se esta midiendo, y mediante una ordenación adecuada se pueden totalizar partes o subconjuntos, o bien deducir huecos después de hacer una medición a cinta corrida etc. Finalmente mediante la suma sistemática de los resultados parciales de cada línea, se obtiene la magnitud total para cada unidad de obra. La presencia ordenada de esos datos parciales en un listado completo, permite hacer en cualquier momento las comprobaciones oportunas para asegurar la correcta integridad del resultado.

Evidentemente la elaboración de esa “medición”, necesita recopilar una cantidad muy considerable de datos numéricos, que lógicamente se presta a la aparición de “errores”, tanto debido a la gran cantidad de datos, como a lo tedioso de su recopilación sistemática. En este sentido cabe destacar la existencia de un “antes” y un “después” respecto a la adopción generalizada de los programas de ordenador y las herramientas informáticas, que permiten almacenar, localizar, o seleccionar, la definición de las unidades de obra dentro de repertorios o bases muy amplias, y por supuesto, guardar ordenadamente los datos numéricos de la medición, asegurando el rigor de todas las operaciones.

La segunda parte en la elaboración de este documento, es la asignación del “precio unitario” o valor económico para la ejecución de cada partida. Evidentemente siempre es posible adoptar dicho valor de una forma seria y rigurosa con arreglo a la experiencia profesional y conocimientos del proyectista, pero también es frecuente que se generen dudas, ya que el resultado final puede estar sometido a intereses contrapuestos para adoptar valores excesivamente “altos” o “bajos”, y por otra parte la facilidad de cualquier programa informático u hoja de cálculo para acomodar el conjunto de precios parciales a una cifra final “predeterminada”, una vez conocidas sus magnitudes es tan simple, que a veces surge la duda sobre la posibilidad de que el presupuesto haya sido arbitrariamente distorsionado.

En el caso práctico de la determinación de los precios del presupuesto, cabe distinguir al menos en nuestro país, el ámbito de los proyectos de “iniciativa pública”, en los cuales la elaboración de ese documento está regulada o condicionada por la “Ley de Contratos del Sector Público”, que obliga a añadir una justificación de los precios adoptados, detallando la descomposición de cada uno entre costes “directos” e “indirectos”, y desglosar a su vez los costes directos en los importes de “mano de obra”, “maquinaria” y “materiales”, detallando todo ello en los cuadros de precios y en su caso, con pequeños presupuestos parciales, con lo que se asegura al menos una coherencia interna más difícil de distorsionar.

Dado que en el caso de las obras de “iniciativa pública”, la licitación, la adjudicación y la contratación de la misma se hacen sobre la base de los precios que figuran en el proyecto, esto supone además que los precios deban ser rigurosos con la realidad, so pena de incurrir en responsabilidad por los perjuicios ocasionados, pero sin embargo en el caso de la “iniciativa privada” como es la mayoría de las obras de arquitectura, esa reglamentación no resulta obligatoria y por tanto la licitación y contratación, se hacen al margen de los precios que figuran en el proyecto, siendo normal que cada contratista proponga su propia lista, o que acuerde las condiciones económicas con el promotor de las obras, sin la participación del arquitecto, o bien que promotor y constructor sean la misma persona en cuyo caso los precios del proyecto ya no tienen ninguna trascendencia sobre la contratación de la obra.

Esto supone que en la práctica habitual, dentro del ámbito de las obras de iniciativa privada, para la elaboración del documento de mediciones y presupuesto, se preste gran atención y cuidado a la definición rigurosa de las unidades de obra y a las “mediciones”, pero sin embargo la determinación de precios unitarios se haga sin demasiada atención, más allá de su contribución proporcional en el importe total.

Ayudantes y Colegas

Tradicionalmente el papel del aparejador se ha basado en una “especialización” sobre la “ejecución de obra” desarrollando un papel más activo en esos aspectos y bastante menor en las cuestiones del diseño, la concepción del edificio o la seguridad estructural del mismo. Esto supone que tradicionalmente era precisamente la figura del “aparejador”, la que dentro de un “estudio de arquitectura” solía hacerse cargo de elaborar las mediciones y presupuesto del proyecto, liberando al arquitecto, de tener que abordar un trabajo, sistemático, tedioso, largo y aburrido.

Por otra parte el papel de los “colegios de arquitectos”, como agrupación profesional ha ejercido una cierta regulación en función de evitar o paliar cierto tipo de competencia entre profesionales, que rebajando artificialmente los presupuestos de sus proyectos, podrían justificar ofertas de honorarios más baratas al estar estos vinculados a la complejidad y magnitud del proyecto y consecuentemente al presupuesto de ejecución.

Esa regulación que trataba de evitar que los presupuestos de los proyectos se bajasen arbitrariamente más allá de un límite razonable, se organizaba mediante un sistema de “módulos”, que se aplicaban sobre la superficie construida del edificio, considerando un cierto repertorio de tipologías con distintos niveles de coste y complejidad, y que con una actualización periódica basada en coeficientes estadísticos, permitía establecer para cualquier proyecto una cifra de referencia que siempre se mantenía ligeramente por debajo del coste real de construcción, pero que a su vez aseguraba una aproximación razonable, aportando la ventaja de establecer una referencia uniforme y objetiva para todos los casos.

Esas circunstancias ha supuesto que en la práctica los presupuestos de ejecución en los proyectos de iniciativa privada, se hayan realizado con mucha frecuencia mediante un “ajuste forzado”  de tipo inverso, de tal forma que los precios de las distintas unidades de obra, una vez que se disponía de la “medición” del proyecto, se forzaban mediante el programa informático o una simple regla de tres, para obtener como resultado final precisamente la cifra de referencia, que estipulaba el sistema de módulos del colegio de arquitectos.

Esta situación ha cambiado drásticamente en los últimos años con la aplicación de nueva legislación que basada en criterios de defensa de la competencia y transposición de directivas europeas, ha suprimido las “tarifas” de honorarios profesionales y ha prohibido cualquier mecanismo o referencia que pueda aproximarse a un sistema de “precios acordados”, para asegurar que los honorarios profesionales se reducen a una acuerdo o compromiso “exclusivamente particular” entre arquitecto y cliente.  

                                                                                                      

Esa desregulación del sistema de módulos que anteriormente establecían los colegios de arquitectos, ha generado que ahora hayan aparecido diferentes sistemas de control sobre los presupuestos, siendo frecuente, que tanto las compañías de seguros que operan sobre la responsabilidad civil en la construcción, como muchos Ayuntamientos que ingresan el impuesto de construcciones dependiendo del presupuesto de ejecución de los proyectos, hayan adoptado cada uno su propio sistema de “módulos” de referencia, con el fin de asegurarse o comprobar que los presupuestos no hayan sido distorsionados arbitrariamente.

PERSONALIZAR el AutoCAD ( y VII )

Programación.

En todos los grandes programas o aplicaciones, suele haber además de las instrucciones y ordenes que ejecuta normalmente el propio programa, la alternativa de “programar” rutinas o acciones, que inicialmente no se han contemplado, pero que algún usuario concreto con conocimientos de programación, puede estar interesado en realizar o adaptar.

Cuando hablamos de entornos de programación, hay que distinguir lo que normalmente se conoce como lenguajes de “macros”, que si bien permiten un cierto nivel de programación, normalmente se limitan a almacenar una secuencia fija de órdenes o comandos ya existentes en el propio programa, para ser ejecutados en una secuencia única, incluso con la incorporación de datos fijos o variables.

En estos últimos casos el proceso interno a nivel de código de programa, que se va ejecutando en la CPU, es la propia secuencia de instrucciones del programa principal, y la rutina tampoco se sale de los límites que tenga asignados dentro del SO (sistema operativo). Cuando se habla de “entorno de programación”, las rutinas que se desarrollan son externas al programa principal y se ejecutan en la CPU del ordenador como procesos diferenciados e independientes, necesitando un control propio desde el SO.

En este aspecto el entorno de programación ha evolucionado considerablemente desde las primeras versiones del programa que se ejecutaban bajo DOS, el cual no disponía de multitarea ni de multiusuario. Después con la evolución desde W95 este panorama ha cambiado y a su vez se ha desarrollado notablemente la programación orientada a objetos, ya sea en C++ o java. También la disponibilidad de Internet y la paulatina implantación del XML, contribuyen a desdibujar o desbordar los límites tradicionales de CPU-SO-Aplicación.

Las alternativas para desarrollar algún tipo de programación dentro de AutoCAD, en la actualidad es múltiple, y el hecho de optar entre una u otra, depende sobre todo de las destrezas o preferencias de cada programador. En las versiones iniciales solo se disponía de LISP, el cual es un lenguaje de alto nivel, basado en el manejo recurrente de “listas”, que al menos en los primeros tiempos, estaba muy asociado con desarrollos de Inteligencia Artificial. Este lenguaje siempre estuvo muy vinculado con AutoCAD, probablemente por las preferencias de los desarrolladores iniciales, pero también porque su peculiar filosofía permite un manejo bastante flexible, de los distintos datos o entidades que soportan la geometría que maneja el programa.

El lenguaje LISP.

El LISP es un lenguaje “interpretado” que se procesa en tiempo real en la línea de órdenes de AutoCAD. Esto supone que sobre la propia línea se puede escribir cualquier instrucción o código de ese lenguaje, siendo inmediatamente procesada en cuanto se pulsa la tecla “intro”. Alternativamente se puede escribir cualquier programa, bajo las especificaciones correspondientes, en un archivo de texto ASCII plano con la extensión “.LSP”, y ser leído desde el propio AutoCAD ejecutando y procesando su contenido de forma inmediata.

El lenguaje LISP se basa en un manejo recursivo de funciones y listas que siempre se escriben entre paréntesis. La “lista” es el objeto básico del lenguaje, ya que cualquier función se escribe como una “lista” de palabras o datos encerrados entre paréntesis. Los elementos de la lista pueden ser: cualquier palabra separada por espacios, un número, una cadena de texto entre comillas, o bien otra lista encerrada a su vez entre paréntesis.

Si se trata de una palabra aislada en principio se interpreta como el nombre de una variable reservando el espacio de memoria oportuno. Si es un número se interpreta con arreglo a su valor numérico, que puede ser entero o real dependiendo de la presencia del punto decimal. El lenguaje admite mezclar operaciones entre enteros y reales, subiendo siempre la categoría al dato más complejo. Si se trata de una cadena entre comillas se considera como tal.

Dentro de los paréntesis se escribe siempre una sucesión de palabras o términos, de las que la primera tiene que ser necesariamente el nombre de la “función” reconocida por el propio lenguaje LISP, y el resto de términos son tratados como argumentos de la misma. Además de esto, cualquier palabra o término que se incluye en la lista puede ser a su vez otra función encerrada entre paréntesis, de tal forma que el conjunto del programa siempre queda organizado como una estructura anidada de “funciones” escritas entre paréntesis.

La ejecución del programa siempre requiere haber cargado en la memoria RAM, todo el paquete de funciones anidadas y a continuación se comienza por evaluar en primer lugar la más interna, y con el resultado se sustituye en la lista que la contenía, pasando entonces a evaluar esa nueva función, y así sucesivamente hasta concluir con la mas externa cuyo resultado se muestra en la línea de órdenes.

Naturalmente el repertorio de funciones disponible en el lenguaje, permite definir y crear nuevas funciones, acceder a los archivos del disco, a las variables de memoria, calcular expresiones numéricas, y realizar diferentes tipos de operaciones con los datos almacenados en las variables etc. La capacidad para programar en este lenguaje lógicamente se deriva de mantener un conocimiento amplio y general de ese repertorio de funciones y de las posibilidades de uso que permiten.

La Ayuda del programa dispone de una parte dedicada al LISP que incluye una descripción pormenorizada y sistemática de todas las funciones incluidas. También dispone de un “tutorial”, en el que se desarrolla un ejemplo interesante, que sirve para generar una orden o comando nuevo, que dibuja de forma automática, una banda de longitud y ancho variables, rellena con círculos de cualquier tamaño. Este ejemplo resulta interesante porque permite comprobar de una forma práctica las posibilidades y el alcance del lenguaje, además de mostrar las peculiaridades del manejo de “listas” y el uso de las funciones más comunes.

En las últimas versiones del programa, se incluye también el entorno “Visual LISP”, aunque esto en el fondo no es mas que un pequeño sistema de ventanas múltiples que incluye un pequeño editor para facilitar la escritura de código LISP, y además va marcando con colores las palabras reservadas, las variables, se identifica la presencia o falta de paréntesis permitiendo localizar y depurar los errores del código con mayor facilidad. En este caso también se puede compilar el código.

Otras alternativas

Además del lenguaje LISP, las versiones recientes de AutoCAD, permiten desarrollar rutinas de programación en otros sistemas, lenguajes o entornos de programación como:

             VBA (Visual BASIC)

             ActiveX

             Objet ARX

             .NET

En todos los casos se usa el paradigma de la “programación orientada a objetos”, y el desarrollo de en estos entornos requiere siempre un conocimiento avanzado de cada uno,  y por supuesto conocimientos especializados de programación. Dentro de esos entornos, particularmente .NET y Objet ARX, se encuentra la posibilidad de desarrollo mediante  lenguajes de programación como C, C++, C#, etc. 

Formas y Tipos de letra.

Las formas son un tipo de objeto cuyo uso es similar a los bloques, aunque presenta ciertas peculiaridades. Una de las ventajas principales es que el manejo de memoria, y la carga del procesador es mucho mas eficiente, por lo que cuando se emplean muchos elementos del modelo puede resultar mas ligero, aunque con el nivel de prestaciones de las máquinas actuales es difícil que pueda llegar a apreciarse la diferencia.

Como inconveniente para el uso de las formas cabe decir que el diseño o dibujo, que va a componer la forma, no puede realizarse directamente en la ventana gráfica, sino que las formas gráficas del dibujo deben traducirse a una “codificación” muy peculiar y luego escribirse en un archivo de texto ASCII, con la extensión SHP, que posteriormente el programa “codifica”, generando un nuevo archivo con extensión SHX, cuyo contenido binario es el que finalmente se maneja.

Uno de los principales usos de las “formas” codificadas son precisamente los “tipos” de letra originales de AutoCAD, que incluso en las primeras versiones se suministraban con las dos clases de archivo, aunque últimamente solo con el codificado SHX. En las versiones actuales del programa también se admiten las tipografías TrueType, pero en este caso no tienen nada que ver con lo que comentamos.

En general el uso adecuado para las “formas” deberían ser elementos gráficos o símbolos relativamente sencillos, con una representación fija que no requiera modificaciones frecuentes, y que se repita mucho, como pueden ser obviamente las forma de tipografía, pero también repertorios de símbolos, para mapas o cartografía, esquemas de instalaciones, notas musicales etc.

Para considerar la posibilidad de crear un repertorio personal de “formas” hay que tener en cuenta que la codificación de un dibujo complejo podría resultar demasiado laboriosa y proporcionalmente sujeta a errores.

En el manual de ayuda, se desarrolla con detalle el sistema de codificación gráfica de las formas, y se incluyen algunos ejemplos que ilustran perfectamente este sistema, e incluso se incluyen un par de archivos con la definición de una tipografía completa.

PERSONALIZAR el AutoCAD ( VI )

Modemacro y DIESEL.

Dentro de la personalización de AutoCAD existe la posibilidad de añadir información personalizada en la “Línea de Estado”.

Recordando uno de los primeros temas del blog, la línea de estado es aquella que se muestra en el borde inferior de la pantalla, y en su configuración incluye de izquierda a derecha, las coordenadas de posición del cursor, ya sea con actualización dinámica según el movimiento del cursor, o estática cada vez que señalamos un punto en el área gráfica de la pantalla. A continuación un conjunto de pulsadores que controlan distintos estados de funcionamiento, como los modos “orto”, “snap”, “refent”, “grid”, etc., y en el lado derecho se incluyen otros tipos de pulsadores con una lista desplegable al final, con el control sobre la posibilidad de mostrar/ocultar estos conjuntos.

Mediante el mecanismo de una variable interna identificada como “MODEMACRO” se puede añadir información personalizada, que se sitúa en el extremo izquierdo de esta línea. La variable se puede invocar desde la línea de estado, y a continuación escribir un texto. El tamaño máximo es de 4.096 caracteres, aunque obviamente se desbordaría mucho antes el tamaño máximo de la pantalla, desplazando fuera los pulsadores y paneles que se muestran normalmente y cuya configuración junto con el tamaño y resolución de la pantalla son los que en la práctica limita el tamaño máximo del texto.

Dentro de esa nueva línea podemos mostrar por ejemplo nuestro nombre, o el de la empresa aunque esa sea una información poco útil. Para ello solo habría que escribir en la línea de órdenes:

               MODEMACRO:  Julio AR

A partir de ese momento veremos que el nombre “Julio AR” se muestra siempre al comienzo de la línea de estado, bien hasta que volvamos a modificar la variable, o hasta que cerremos la sesión, ya que el contenido de la variable es volátil y no se guarda en el archivo de dibujo.

Lógicamente esa información “fija” es poco relevante, pero el programa dispone a su vez de un lenguaje de macros conocido como “DIESEL”, que permite ampliar esa información de una manera mucho más útil, como puede ser el nombre de la capa actual, del color, del tipo de línea, del estilo de texto o de la acotación, y en general cualquier valor contenido en alguna variable interna del programa.

El lenguaje de macros “DIESEL” se explica en la ayuda, y básicamente permite escribir expresiones basadas en el repertorio de funciones que se enumeran, las cuales tienen un formato similar al LISP aunque precedidas por el símbolo “dólar”, de la siguiente forma.

             $( funcion, variable1, variable2, .. )

Una función interesante para este uso es “ $(getvar, variable) “ que es la que permite consultar en cada momento el contenido de las variables del programa, en particular para mostrar el color actual, tipo de línea, estilo etc.

Concretamente vamos a ampliar la información de la línea de estado, incluyendo el color, la escala de tipo de línea y el estilo de texto actuales. Esa infamación si consultamos las variables del sistema a través de la ayuda correspondiente, se encuentra en las variables: “CECOLOR”, “LTSCALE”, y “TEXTSTYLE”.

Por tanto tendremos que escribir un valor para “modemacro” que incluya el texto de referencia y en su lugar las llamadas a las funciones capaces de mostrar sobre esa línea de texto, los valores correspondientes. Esto sería algo así como:

MODEMACRO: Color Actl: $(getvar, cecolor) – Estilo Texto: $(getvar, textstyle) – Escala de tipo de Línea: $(getvar, ltscale)

Evidentemente esta configuración se pierde cuando cerramos el programa, pero nada impide escribir esa macro en alguna opción particular de menú personalizada mediante la interfaz CUI que habíamos comentado en las entradas anteriores.

Fotos y Archivos de Comando.

En el momento actual, el problema de realizar “presentaciones” sobre cualquier contenido, ya sea de “AutoCAD” o de otros programas, ha cambiado notablemente con respecto a las primeras versiones, que ya disponía de una difusión universal y generalizada desde mediados de los años 80s, cuando el uso de programas como “Power Point” o los formatos PDF resultaban inimaginables.

En aquellas primeras versiones, el programa disponía de un sistema propio, que lógicamente se ha mantenido por compatibilidad hacia atrás,  y que en la actualidad se encuentra en desuso. El sistema propio se basa en la posibilidad de “capturar” imágenes asiladas, exclusivamente del área gráfica de la pantalla, y posteriormente poder mostrarlas mediante una secuencia escrita en un archivo de comandos, que el propio programa puede ir mostrando paulatinamente con retardos programados, de una forma completamente “desatendida” lo cual podría resultar útil en ciertos entornos como ferias o exposiciones.

Esa secuencia de “imágenes” previamente guardadas en archivos independientes se muestran en la pantalla gráfica superpuestos a la imagen actual, pero cualquier acción sobre el teclado, ratón, o menús o la ejecución de otro comando, hacen que la pantalla se actualice y por tanto se pierde la imagen mostrada.

Las imágenes o capturas se denominan “slides” y el programa dispone de un par de comandos, que sirven para realizar o mostrar la captura de esa imagen gráfica. Estas son “SACAFOTO(_MSLIDE)” y “MIRAFOTO(_VSLIDE)”. Estas órdenes se pueden ejecutar desde línea de órdenes, de forma que en el primer caso nos pedirá una carpeta o dirección para situar el nuevo archivo, y en el segundo el nombre del archivo que se quiere mostrar.

El archivo de comandos no es más que un archivo de texto plano (formato ASCII puro), con la extensión “*.SCR” (script) en el que se va escribiendo cada comando en una línea diferente. El archivo puede contener cualquier comando salvo aquellos que despliegan un cuadro de diálogo, aunque normalmente estos suelen disponer de versiones alternativas sin el cuadro de diálogo.

Existe además algún comando como “RETARDA(_DELAY)”, que resulta bastante útil en este tipo de archivos ya que provoca un retardo en milisegundos igual a la cifra que se incluya, hasta que se procesa el siguiente comando de la lista. A continuación se muestra como ejemplo, un fragmento de un archivo que muestra las imágenes empaquetadas en t61(b100) .. b101) .. b102) con retardos de 1 segundo.

_vslide t61(b100)

_delay 1000

_vslide t61(b101)

_delay 1000

_vslide t61(b102)

_delay 1000

PERSONALIZAR el AutoCAD ( V )

En la entrada anterior se describe la forma de modificar o personalizar la “interfaz” de AutoCAD. Aunque comentado todo ello en abstracto, todo el mundo reconoce el interés de ese tipo de modificaciones, dado que siempre resultan complejas y generan una cierta inseguridad en cualquiera que no disponga de una cierta soltura de manejo, también existe una tendencia natural a considerar este tipo de aspectos como algo “lejano”, que solo es útil para “especialistas” que se dedican profesionalmente a esos desarrollos.

Con el fin de romper en la medida de lo posible, esa suposición inicial, voy a tratar de desarrollar un ejemplo práctico, construyendo una pequeña personalización sobre AutoCAD que pueda resultar útil a modo de ejemplo.

                             

Voy a centrarme en la elaboración de un pequeño “menú desplegable” para insertar de forma rápida, un repertorio de “aparatos sanitarios”, ya que esta es una tarea relativamente común en la elaboración de una planta de arquitectura, y aunque tampoco resuelva grandes problemas, si puede servir de muestra sobre una forma de abordar “la personalización” para acceder a un repertorio de bloques que se insertan con frecuencia en diferentes archivos de dibujo.

Los bloques.

En primer lugar es preciso recopilar el conjunto de bloques que queremos agrupar en el nuevo menú. Este puede ser más o menos amplio, pero es conveniente agruparlo en alguna carpeta del disco, donde se puedan localizar con facilidad, y que probablemente con el tiempo vayamos modificando y/o adaptando a nuestro gusto particular. En primer lugar el repertorio va a ser bastante escueto para no extender el ejemplo, y se compone de un lavabo, bidet, inodoro, una ducha y una bañera, que una vez seleccionados, dibujados o elaborados, debemos colocar como dibujos independientes en una carpeta de nuestro disco, por ejemplo “[BLQS]”.

El nombre de los bloques es indiferente, ya que cada vez que vayamos a insertar un determinado bloque, el nombre del archivo estará escrito dentro de la “macro” o comando que automatiza esa tarea, y nosotros solo debemos “recordar” la ubicación del menú y nombre de etiqueta que hemos colocado en él, pudiendo incluso asociarle una pequeña imagen o gráfico a modo de “icono” con un tamaño de 32x32 pixel. Lo que si es importante es que el “path” o trayectoria de la carpeta donde están los bloques, se encuentre dentro la “Ruta de búsqueda de archivos de soporte” que si no estaba incluida se puede añadir con facilidad  en cuadro “opciones”, solapa “archivos”.

El nuevo Menú.

Una vez que tenemos recopilados nuestros bloques en la carpeta, sin olvidar ajustar el “punto base” de cada uno, sobre un punto singular que después resulta fácil de situar en el archivo de trabajo, cuando vayamos a insertar cada bloque. Para desarrollar el ejemplo vamos a situar un nuevo menú desplegable que llamaremos “Aparatos Snt.”, y a su vez cuando se despliegue va a contener, los bloques mencionados con arreglo al siguiente esquema:

             Aparatos Sntrs.

                           Lavabo

                           Bidet

                           Inodoro

                           Ducha

                           Bañera

Si recordamos el funcionamiento del cuadro de personalización, los pasos a seguir, son en primer lugar definir un nuevo comando para poder insertar cada uno de los bloques. Después de haber definido los cinco comandos, debemos crear o definir el nuevo menú desplegable, dentro del cual vamos a colocar los comandos. Una vez hecho esto debemos guardar el nuevo menú como un archivo “CUIx” independiente, para poder modificar o ampliar en el futuro y finalmente tenemos que trasladar o insertar el menú que hemos creado dentro del general que utilizamos en nuestro espacio de trabajo.

Los nuevos comandos.

En este punto hay que advertir que posiblemente este sea el paso más crítico o delicado, ya que en la definición de un nuevo comando, es preciso ser muy cuidadoso con todos los caracteres que se escriben, ya que cada espacio en blanco se interpreta dentro del programa como una pulsación de la barra espaciadora o la tecla “intro”. Por otra parte es preciso identificar perfectamente todas y cada una de las respuestas opcionales que tiene el comando invocado, porque cualquier desajuste siempre genera respuestas imprevistas.

La definición de cualquier nuevo comando no es más que una cadena de texto, que se anotará de forma literal en el campo correspondiente, comenzando con el nombre de la “orden” que se quiere invocar, a continuación el espacio en blanco que inicia su ejecución, e inmediatamente las respuestas o textos que requiera cada una de las opciones de esa orden concreta.

Hay que tener en cuenta que tanto el espacio en blanco como el carácter “;” son equivalentes a una pulsación de la tecla “intro” o a la barra espaciadora. El carácter “\”, genera una parada en la secuencia, que permite un respuesta del usuario ya sea señalando un punto de la pantalla, o bien escribiendo por teclado algún texto o dato que se cierra con una pulsación del “Intro”. Los datos fijos se pueden escribir dentro de la secuencia de pulsaciones de forma literal, aunque sin olvidar el comportamiento del espacio en blanco o encerrando la cadena entre comillas.

Hay que pensar que un solo espacio en blanco de más, al principio o al final de la secuencia, va a generar un “eco”, que trata de repetir la última orden ejecutada por el sistema, lanzando el mensaje correspondiente, y si las respuestas anotadas no se encuentran sincronizadas, el resultado final que se genera va a ser un “error”. Con el fin de probar y ensayar la nueva secuencia, es conveniente tratar de probarla mediante la línea de órdenes, contando y verificando las pulsaciones de una en una.

En el caso de nuestro ejemplo el nuevo comando que nos interesa se compone de una llamada a la orden “_INSERT”, y a continuación se añade el nombre del bloque que queremos insertar en el dibujo. Luego debemos programar una detención del comando para poder señalar en pantalla, el nuevo punto donde se situará exactamente el bloque que hayamos elegido. Una vez situado el punto de inserción, hay que tener en cuenta que la ejecución “paso a paso” del comando requiere otras tres respuestas, que son a su vez los factores de escala en las direcciones X e Y y el ángulo de giro para el nuevo bloque insertado.

En el caso que nos ocupa evidentemente los factores de escala en las direcciones X e Y deben ser “1”, por lo que en el comando será oportuno confirmar la opción por defecto o pulsar “Intro”, es decir escribir un “;”, sin embargo en el momento de fijar el ángulo de giro resulta oportuno devolver el control al usuario, para que el ángulo con que se inserta el bloque pueda fijarse gráficamente, es decir que debemos escribir en su lugar un “\”. Esta entrada debería terminar la ejecución de la nueva orden por lo que le línea de texto debería tener el siguiente aspecto: 

_INSERT <bloque> \;;\

El hecho de escribir el nombre de la orden en ingles precedida del subrayado de mayúsculas, se hace porque con esta notación, la orden funciona dentro de AutoCAD con independencia del idioma al que se haya traducido el programa, sin embargo si escribimos la versión “traducida”, solamente funcionara en aquellas versiones traducidas al idioma en cuestión.

Además de forzar la versión en ingles, del comando de base, es conveniente escribir al comienzo de la línea, dos veces la pulsación [Ctrl+C] con el fin de “romper” o anular cualquier posible orden transparente que pudiera estar en curso de ejecución en ese momento, lo que produciría un “error”. La forma de escribir por teclado esa pulsación es “^C”, con lo que el texto que debemos escribir en la macro quedaría:

             ^C^C_INSERT <bloque> \;;\

Ensamblar el conjunto.

Una vez que está clara, la estructura del nuevo menú y como escribir cada comando, ya solo queda ensamblar el conjunto en un nuevo archivo personalizado.

Para ello abrimos el cuadro de la interfaz de personalización, nos situamos en la solapa “Transferir”, y desde el panel derecho, accionando la opción “nuevo” podemos crear un nuevo archivo con la extensión “*.CUIx” que situamos a nuestra conveniencia dentro de las carpetas del disco.

Posteriormente pasamos a la solapa “Personalizar”, y desde la cabecera abrimos el nuevo archivo y en la lista desplegable lo seleccionamos, con el fin de mantener los nuevos comandos y sus ajustes o modificaciones asilados del resto de los archivos de personalización.

                                                                                             

Una vez situados sobre el nuevo archivo, abrimos el “nodo” de menús, y en él con ayuda del botón derecho dede el menú contextual, “creamos” el nuevo menú que vamos a llamar “Aparatos Sntrs.”.

A continuación pasamos al modulo inferior del cuadro que corresponde a la “Lista de Comandos” y que inicialmente debe encontrarse vacío porque aún no hemos definido ninguno. A la derecha en la barra de cabecera hay un botón que sirve para “crear un comando”, que una vez pulsado, nos presenta un nuevo aspecto del panel derecho, donde podremos editar o definir el nuevo comando y sus propiedades, incluido su nombre, la macro asociada y otros campos de ayuda.

A continuación vamos configurando cada nuevo comando, (Lavb. Duch. .. etc.) y en el campo de la macro escribimos el texto correspondiente actualizando debidamente el nombre del bloque que vamos a insertar. Finalmente cuando tenemos en el panel izquierdo toda la lista de los nuevos comandos ya solo queda subirlos al menú que habíamos creado y que se encuentra en el árbol general del panel izquierdo.

Cuando hemos acabado, solo queda salvar el nuevo archivo, y a continuación volvemos a pasar a la solapa “transferir”. Entonces seleccionamos en el panel izquierdo el archivo de personalización principal, y en el panel derecho el nuevo archivo que hemos creado, y solo nos queda trasladar con la pulsación sostenida, el nuevo nodo de menú desde el panel derecho a la ubicación que resulte oportuna del conjunto completo que tenemos en el panel izquierdo.

Finalmente accionando el botón “Aplicar” de la parte inferior, el sistema actualiza todo los archivos y presentará en nuestro espacio de trabajo el nuevo menú, y a partir de ese momento deben encontrarse disponibles los nuevos comandos.

PERSONALIZAR el AutoCAD ( IV )

La interfaz de usuario

Una de las características que siempre ha tenido AutoCAD desde las primeras versiones, es su gran capacidad y flexibilidad, para poder modificar la “interfaz” de usuario, adaptando esta a las necesidades o preferencias personales de cada uno.

El concepto de “interfaz”, básicamente se debe considerar como el aspecto y configuración que tiene la pantalla o ventana del programa, durante el proceso de trabajo habitual, que es a través de la que vamos cargando, seleccionando o ejecutando las órdenes que deben actuar en cada momento, además de incorporar o definir los datos de cualquier tipo, con los que vamos construyendo nuestro archivo de trabajo.

Normalmente en las primeras versiones del programa la interfaz de usuario estaba constituida por un área de menús, situada en la parte derecha de la pantalla y una pequeña zona inferior para la línea de comando con capacidad para tres o cuatro líneas de texto. El resto de la pantalla estaba ocupada por el área gráfica donde se visualizaba el dibujo que íbamos construyendo. También disponía naturalmente de una barra de título y otra de estado, donde se mostraba la información correspondiente.

El repertorio de órdenes y comandos que ha tenido disponible el programa desde sus primeras versiones ha sido muy extenso, por lo que los menús de comando tenían que disponer de algún mecanismo o sistema que permitiera ordenar racionalmente ese gran repertorio, con una estructura “anidada” o de cualquier otro tipo, para poder alcanzar tanto las diferentes “ordenes” del programa como las opciones o alternativas para la ejecución para cada una.

Por otra parte la extensión y repertorio de órdenes que se encuentran disponibles en un programa de propósito general como este, es singularmente amplio aunque sin embargo a la hora de realizar el trabajo cotidiano muchas de sus características y opciones, son formas alternativas para realizar tareas similares. Ello supone que cada usuario se va acomodando por una parte a utilizar solamente algunas órdenes con las que se siente más cómodo y por otra parte las peculiaridades de cada trabajo concreto, también contribuyen a que haya ciertos conjuntos de órdenes o alternativas que en la práctica cotidiana son poco utilizadas. El programa también permite con relativa facilidad adaptar o acomodar el uso de distintas órdenes u opciones, a un comportamiento diferente en función del uso particular, o los gustos de cada usuario. Todo esto es la base de la “personalización” del programa.

La personalización desde las primeras versiones, se desarrollaba mediante archivos [ *.MNU ], que estaban configurados como archivos de texto ASCII plano, que se podían editar o modificar mediante editores como “notepad”, o cualquier otro que no intercalase dentro del contenido, sus propios códigos. El programa se suministraba siempre con un archivo denominado “ACAD.MNU”, que se iniciaba por defecto en el arranque y contenía la estructura inicial de los distintos menús, que configuraban la interfaz, tanto de la pantalla como la tableta digitalizadota, o la pulsación de los botones del ratón.

 

La estructura interna de esos archivos esta dividida en secciones, donde se escribe mediante sucesivas líneas de texto, el término que debe mostrar el menú encerrado entre corchetes, y a continuación las órdenes u opciones del programa exactamente igual que si se estuvieran escribiendo mediante el teclado en la línea de órdenes. Dentro de las instrucciones que se pueden escribir también se incluye cualquier rutina de “AutoLISP”, ya sea escrita directamente o bien a través de la carga de archivos escritos en ese lenguaje, que el programa “interpreta” en tiempo real, con lo que las posibilidades para ampliar o personalizar cualquier comportamiento de nuevas órdenes u opciones mediante un menú añadido con ese mecanismo, no tiene más limites que la propia imaginación.

Evidentemente tanto la depuración como la necesidad de comprobar que las rutinas funcionan con arreglo a las previsiones, constituyen una parte muy importante de todo este proceso. El programa en las versiones anteriores, permitía cargar módulos o partes que podían estar distribuidos en varios archivos con la extensión MNU, no obstante a partir de la versión de 2.006 se produce un cambio profundo, implantando el uso de un nuevo cuadro de “Interfaz de personalización”, que se complementa con el manejo de un nuevo tipo de archivos [ *.CUI ] ó [ *.CUIx ], que a fin de cuentas son archivos de tipo XML, en los que se centralizan y gestionan todos los datos de personalización que antes estaban en los archivos MNU, y que son actualizados de forma automática por el programa, evitando la modificación del archivo por el usuario mediante un editor.

El cuadro de Personalización.

Los antiguos archivos MNU, se pueden incorporar perfectamente en la nueva estructura, pero los archivos CUI, ya no son modificables mediante el editor de texto, sino que el programa incorpora una orden que despliega en pantalla un “cuadro de personalización”, desde el que se accede a todas las ordenes y opciones, cuyo contenido puede ser editado y modificado dentro de ese cuadro, a gusto de cada uno. Finalmente cuando se cierra el cuadro, el propio programa realiza internamente la actualización del correspondiente archivo CUI con las modificaciones realizadas.

El cuadro de personalización, se encuentra dividido verticalmente en dos partes, y dispone a su vez de otras dos solapas que controlan los estados alternativos de “Personalizar” y “Transferir”. La diferencia entre ambos radica en el uso del panel derecho, que en el caso de “Personalizar”, sirve para ir abriendo detalles o componentes de los elementos y nodos que se van seleccionando en el panel principal de la izquierda. En el caso de la opción “Transferir”, el panel derecho se utiliza para abrir, guardar o configurar archivos parciales.

El panel principal situado a la izquierda, muestra inicialmente una estructura en “arbol” que contiene todos los elementos personalizables del programa. Cuando se encuentra activo el modo “transferir” solo se muestra la estructura del arbol, y permite “copiar” o “trasladar” entre ambos paneles cualquier elemento o rama de la estructura, con la pulsación sostenida del ratón.

Cuando se encuentra activo el modo “personalizar”, la estructura se complementa en la parte inferior con un cuadro que muestra una lista completa de los comandos disponibles. A medida que se van marcando o abriendo los distintos nodos del árbol o bien los comandos de la lista inferior, el panel derecho va mostrando un texto aclaratorio sobre la función de cada uno, o bien los componentes detallados que configuran el elemento, y que son mostrados en campos de texto para que se pueden modificar y/o reescribir oportunamente sobre el panel derecho.

La estructura completa del árbol es bastante amplia y compleja por lo que lleva cierto tiempo familiarizarse con el conjunto, pero resulta muy fácil y cómoda de manejar. Uno de los primeros nodos de la estructura en árbol, es la de “espacios de trabajo”, que constituyen la herramienta básica para poder gestionar distintas configuraciones de personalización.

Los “espacios de trabajo”, constituyen la forma de guardar o recuperar una determinada configuración o aspecto de la Interfaz de usuario o espacio de trabajo. A fin de cuentas no son mas que “etiquetas”, que genera el propio usuario, y que almacenan y por tanto permiten recuperar posteriormente un determinado aspecto de la interfaz de usuario, en la que se visualizan y colocan en las distintas zonas de la pantalla los menús de barra, persiana, cinta o paletas, que usuario tuviera desplegados en la pantalla, cuando ha creado o actualizado esa etiqueta o nombre concreto.

El programa suministra por defecto cuatro espacios de trabajo que corresponden con otras tantas configuraciones de la interfaz, concebidas para facilitar el trabajo básico de dibujo y anotación en dos dimensiones, o bien un par de variantes para trabajo de modelado en 3D, y otra más para evocar el aspecto clásico del AutoCAD.