Controles habituales Conceptos básicos
Cuando el concepto actualmente seleccionado es de tipo Carpeta, al abrir la ventana de propiedades del conceptos de cualquiera de las formas posibles (mediante la opción Concepto > Ventana Propiedades o la de Concepto > Propiedades > Propiedades Carpetas, o haciendo doble clic con el ratón sobre el icono de Tipo), se muestra esta ventana.
Como todas las ventanas de propiedades de Tipos con varias Clases, en la barra de título se muestra el rótulo <tipo> · <clase>
En este caso las Clases no aportan funcionalidad especial y se suelen crear para distinguir con iconos o poner campos especiales en: secciones o separadores de conceptos, capítulos, presupuestos, etc.
Una carpeta puede tener debajo:
1. Una lista explícita de conceptos, mostrando una relación jerárquica (capítulos y subcapítulos por ejemplo), como los directorios de un disco. Este relación es N a N, lo que quiere decir que lo que esté 'colgado' bajo una carpeta, también puede estar a la vez bajo otras cualesquiera. Estas relaciones se pueden hacer simplemente copiando y pegando líneas de conceptos, por ejemplo con Control+C y Control+V
2. Una lista de conceptos resultado de una búsqueda con una Select (completa o reducida) o un procedimiento Javascript. La búsqueda se realiza cada vez que se entra en la carpeta.
3. Conceptos 'asociados' o 'colgados' automáticamente por herramientas especiales (como informes o búsquedas contextuales)
El conmutador Doble altura en lista de hijos permite que las líneas de conceptos descendientes de la carpeta (sean hijos reales o el resultado de una búsqueda) se muestren con un icono de tamaño doble que el habitual, el tamaño de la fuente de texto también es el doble y los iconos de tipo, también.
El conmutador Vista en modo imágenes, fuerza que los hijos (sólo los directos de la carpeta) se muestren como un panel de diapositivas ordenadas de izquierda a derecha, en vez de una lista de líneas. En la diapositiva se mostrará el primer gráfico asociado, si tiene, y sino, el icono de 32 puntos correspondiente. La navegación se puede realizar con los clic izquierdo y derecho del ratón, de la forma habitual. Este modo se puede configurar en color e información que muestra en la ventana Opciones.
El conmutador Actúa sobre el archivo paralelo, es una marca especial para hacer que se abra la ventana del paralelo y se realice la búsqueda, o bien se ejecute en ella la función de JavaScript. Cuando este conmutador está marcado, el icono de la clase de concepto muestra una marca amarilla como una chispa.
El campo Cabecera de lista de hijos permite introducir un nombre para la configuración de cabecera de sus descendientes, si queremos que sea distinta de las demás. Si aparece en blanco, será igual a todas las que están en blanco (la de defecto), y de forma análoga, podemos utilizar ese nombre de configuración en cualquier otra carpeta al cambiar cualquiera de ellas, cambian todas las carpetas que utilizan esa configuración.
El campo Tipo y clase asociada, permite relacionar la búsqueda actual con uno de los tipos y clases de conceptos. De esta forma, en el menú contextual que se muestra haciendo clic derecho en la columna Tipo (submenú Concepto > Concepto actual), se mostrará como última opción esta búsqueda, pero sólo en los conceptos de ese Tipo o Clase. También se mostrará bajo los objetos de esa clase, como 'descendiente'.
Es un campo de texto multilínea que permite introducir una búsqueda con unas reglas particulares:
- Se admiten comentarios con sintaxis de Javascript // o /* */
- Si comienza con la palabra SELECT se considera una sentencia sql, pero puede ser una sentencia SQL incompleta.
Esto es válido también para Carpetas de clase Búsqueda JavaScript.
- El resultado de la búsqueda deben ser identificadores de conceptos (tabla CON de cualquier BD de la aplicación) o relaciones (tabla RCC) que se mostrarán como descomposición de la carpeta; serán hijos "virtuales" de la carpeta a diferencia de cuando el campo Clase está en blanco (se trata de un concepto Carpeta genérico) y la lista de hijos son relaciones explícitas.
- Las consultas siempre deben devolver una lista de identificadores (procedentes de conceptos o de relaciones), por lo que detrás de "SELECT" siempre irá el nombre "ide" o un campo de una tabla, que contenga identificadores.
- Además se admiten unas macros particulares del programa, no de SQL, que amplían la potencia de la propia SELECT:
Esto añade potencia para modificar mediante parámetros las búsquedas (así el comando de búsqueda no es fijo con un nombre de tabla o de campo, sino que el programa usa datos de la selección de conceptos o pide datos al usuario.
|
Estos ejemplos se pueden probar en la base Ejemplos\Edificio.ing: EJEMPLO 1: La sentencia: select ide from con where tip=3 and muestra un diálogo con el rótulo: "Campo de ordenación", y busca los descompuestos de la tabla de conceptos, que sea de tipo Referencia externa y que en el campo padres de la tabla de relaciones solamente tenga uno. La ordenación de la lista resultante la realiza por el código de campo que se introduzca en el diálogo (por ejemplo CON o RES). EJEMPLO 2: select ide from rcc EJEMPLO 3:
select ide from _iluman where padi in ( |
Además del SQL estándar, la aplicación admite una sobrecarga de la SELECT en cualquier sitio en que se haga uso de SQL (informes, carpetas de búsqueda, programación de servidor, consultas directas de SQL desde la pestaña SQL...).
Cuando vemos todos los datos de un concepto de una clase estática o dinámica, como en el ejemplo Edificio.ing: "iluman · Cuadro de mando" del tipo "ilu · Iluminación", estamos viendo datos de tres tablas relacionadas por el campo IDE:
1. CON (conceptos) donde está el Código (con.cod), el Resumen (con.res) y el Texto descriptivo (con.tex), por ejemplo.
2. la tabla del tipo: ILU donde están los campos comunes a todos los elementos de inventario de iluminación (en este caso no tiene)
3. la tabla de la clase: ILUMAN que tiene los datos propios sólo de los elementos de clase Cuadro, y es una extensión del tipo ILU, y que contiene los valores de acometida (ILUMAN.acoest), contador (ILUMAN.conmar), etc.
Si se quiere hacer un cruce de datos de las tres tablas, por ejemplo, para obtener en ventana principal:
la lista de conceptos (identificadores) de todos los Cuadros Estado de Acometida (que es un campo de tipo lista de rótulos) "Bueno" (que tiene el código "B") y que esté asociado al Servicio "ES0018 · Cuadro General" (este es el código del concepto asociado como Ascendiente o 'padre' único en el campo con.padi), ordenados por código de Cuadro, tendríamos que hacer una consulta como:
select ide from con where ide in
(
select ide from ILUMAN where acoest=
(
select ide from rot where tip=1000015 and cod="B"))
and padi= (select ide from con where tip=31 and cla=15 and cod="ES0018")
order by cod
En cambio, con el SQL sobrecargado de Ingrid, basta con:
select ide from _ILUMAN where _acoest="B" and _padi="ES.ES0018" order by cod
El intérprete, al ver las marcas de campos y tablas que en Ingrid llamamos "virtuales", con la un guión bajo (_) delante, ya sabe que debe poner accesibles todos los campos de CON, VIA y BARR. Claro, en el modelo de datos NO puede haber campos con el mismo nombre en la tabla de una extensión (clase), su Tipo y la tabla CON.
Además con el campo "acoest" virtual, podemos comparar directamente con el código sin buscar el rótulo ni el identificador del rótulo que corresponde a ese campo. Otro ejemplo es el campo virtual "padi" que podemos comparar directamente con un par <clase>.<código> o <código> (este último puede ser ambiguo).
Si quisiésemos ordenar una lista de Circuitos por código de Ascendiente (Planta) y luego, en los que coincidan, por Fase al revés (T.S.R), sería una Select más compleja que con:
select ide from _ILUCIR order by [padi],[fas] desc
IMPORTANTE: la implementación sólo involucra los 3 niveles de tablas vistos: CON, las de Tipos y las de extensiones o clases dinámicas, Para hacer cruces entre tablas internas de georreferencias, gráficos y mantenimiento hay que utilizar las referencias normales en SQL.
SENTENCIAS JAVASCRIPT
En la subpestaña Búsqueda SQL, los identificadores que se van a mostrar 'debajo' de la carpeta pueden ser resultado de un programa Javascript. Se usa cuando la búsqueda de identificadores es más compleja y no basta con una sentencia select, sino que hace falta más código y funciones. Hay una referencia completa en la ayuda anexa, y una referencia sencilla en el tema Lenguaje JavaScript, además con la potencia de las extensiones COM añadidas por el programa.
Si no hay definida una función con el nombre sqljs(), se encapsula lo que se encuentre en la pestaña dentro de este código:
bas=Cbas; function sqljs(){ <código de la pestaña> }
De forma que la sintaxis más sencilla es un comando return con una lista de identificadores de la tabla CON (por ejemplo: return [123, 100, 1007];) EJEMPLO: La función más sencilla:
var bas=Cbas; function sqljs() { return bas.buscaN("select ide from con"); }
es equivalente a la línea: select ide from con
Si existe la función, no se encapsula en código, y se interpreta en JavaScript tal cual está. Esto se admite por si hace falta utilizar otras funciones que interactúen con esa, por ejemplo).
IMPORTANTE: hay una notación para devolver una lista de identificadores de relaciones (tabla RCC de la base de datos) y es poner el identificador como número negativo.
Botones de la subpestaña:
El botón Ejecuta búsqueda permite lanzar la búsqueda desde la ventana, sin tener que ir al concepto en ventana principal y hacer doble clic en él.
Los demás botones y subpestañas son los estándar de todas las ventanas de propiedades.
Esta pestaña tiene un uso igual a la siguiente: Cabeceras comunes, sólo que las cabeceras definidas aquí tienen como ámbito sólo el archivo de B.D. actual. Para definir cabeceras comunes a todos los archivos que manejemos, debemos hacerlo en la siguiente pestaña.
El ámbito de estos formatos de cabeceras y campos, es el programa. Las definiciones que aquí se dan, se graban en un archivo externo y se pueden utilizar en todas las B.D.
Tiene exactamente la misma funcionalidad que la anterior, pero en vez de guardarse los datos en un campo de la tabla de cabecera de la base de datos (es decir están sólo en el archivo actual), se graban en el archivo externo tabcar_cabcam.dat del subdirectorio \MACROS, y las definiciones son comunes a todos los archivos que utilicemos.
Se compone de una lista multilínea que muestra todas las configuraciones de cabecera de listas que hay definidas para el archivo de base de datos actual. La pestaña se muestra en color azul por esa razón: los datos de esta pestaña NO son contextuales al concepto Tipo Carpeta seleccionado, sino comunes a todo el archivo. Los datos de esta pestaña se guardan el campo bas.cab.carcab de la B.D. (tabla de cabecera).
IMPORTANTE: Esta configuración de campos, no es la que obligatoriamente se va a mostrar en la ventana principal, sino que define los datos QUE SE PUEDEN mostrar y elegir en el menú contextual de cabecera de listas.
En el campo Campos definibles (uno por línea), podemos definir cada campo, con la sintaxis que se muestra en el rótulo:
[cabecera>][rotulo:][-@]tabla[|codigo].campo[{.campo}]
La notación de este formato es la siguiente: lo que va entre corchetes '[ ]' significa que es opcional y puede no ponerse, las llaves '{ }' indican opcional y además que se puede repetir varias veces de la misma forma, y los demás caracteres son literales, es decir, que son caracteres para teclear '· : @ |'. Los dos términos en negrita son los únicos obligatorios SIEMPRE en cada definición de campos.
El orden de las líneas de campos se tiene en cuenta, y es el que permite personalizar el orden de las columnas de izquierda a derecha en la ventana principal.
Cada campo puede tener definido un código cabecera (por el que se la identifica y que se asigna en la pestaña Carpeta), si no lleva nombre de cabecera, se considera que es para todos los Tipos y situaciones de conceptos.
El código cabecera se usa para definir en qué estado esta, como padre, como hijo, etc. va a aparecer el campo. Es decir, si queremos que se asocien las cabeceras AUTOMÁTICAMENTE SEGÚN EL TIPO DE CONCEPTOS, la primera parte del código debe coincidir con las 3 ó 6 letras del nombre de la tabla, y estar seguido de uno de los indicadores: 1-concepto como padre, 2-concepto como hijo.
Cada campo debería tener un rótulo que será el texto que aparece en el botón de cabecera. Obligatoriamente, una tabla a la que se refiere, y un campo que es el que queremos mostrar.
El signo menos (-) delante de la tabla, indica que no mostrará campo de edición.
Se incluye el carácter arroba (@) para especificar campos virtuales (no existentes en campos de la B.D., pero accesibles como si lo estuvieran).
El codigo que va detrás de la tabla separado con una barra vertical (|), sirve para identificar uno de los valores de tablas que se componen de rótulos (relaciones de tablas N a N). Pero lo normal no es definir un valor de codigo para un campo, sino un campo de una tabla. Además como se puede observar por la notación entre llaves ({}), se admite una concatenación de campos de forma que el valor de uno puede ser una referencia a un campo de otra tabla, de la que se recupera el campo y a su vez puede apuntar a otra tabla, etc.
Por ejemplo:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 |
// General Pendiente:con.pen Cod_Res:con._codres Estado:doc.est.res // Carpetas car1>Mantenimiento:tex|man.tex car1>Cantidad:rcc.can car2>Proveedor:doc._ent // Otros var1>Antigüedad:con.fecant doc1>Contrato:doc.cnt |
- LIN 1: Se admiten líneas que comiencen con doble barra inclinada (//) como comentarios que no se tienen en cuenta al interpretar los campos
- LIN 3: En el campo 'Cod_Res' mostramos un campo virtual -contiene el contenido de otros dos campos para mayor facilidad de acceso: código (cod) y resumen (res)-.
- LIN 4: Accedemos al campo 'Estado' de documentos, que es una referencia a un rótulo (tabla ROT), y mostramos la descripción de ese rótulo concatenando los campos directamente.
- LIN 8: 'Cantidad' muestra (si lo abrimos en la ventana principal), la cantidad que ya existe como campo, pero nos sirve para ver que podemos mostrar un campo predefinido en otra posición que la que ya tiene. Se muestra donde haya una carpeta como padre (car1·).
- LIN 9: Muestra un campo de documentos, cuando aparezcan carpetas como hijos (car2). Si en un nivel de la estructura aparecen carpetas a la vez como padre y como hijos, sólo aparecen los campos definidos para hijos.
- LIN 12: En las listas de Tipo Elemento (tabla 'VAR'), podemos mostrar en el campo 'Antigüedad' una fecha SÓLO SI tenemos definido en la ventana Tipos de conceptos, un campo 'fecant', ya que este campo no existe en la tabla CON (concepto). Lo mismo sucede con el campo 'pendiente' de la línea LIN 2.
- LIN 13: 'Contrato' muestra un campo de documentos, sólo donde tengamos documentos como padre (lo que no es habitual).
IMPORTANTE: Hay una notación que no está documentada en ese formato de sintaxis, que consiste en cambiar un identificador de una tabla a otra mediante dos puntos seguidos (..), por ejemplo, ord2>ord.coni..viv.nivel muestra en las listas de órdenes de trabajo (ord2) el campo nivel de la tabla viv a la que se hace referencia desde el campo de concepto a mantener (coni) de la tabla de órdenes (ord).