Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Parent-child relations
Message
From
18/04/2002 10:43:21
Hilmar Zonneveld
Independent Consultant
Cochabamba, Bolivia
 
 
To
17/04/2002 21:30:39
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00645271
Message ID:
00646342
Views:
19
>>Yo me olvidaría del Grid, y utilizaría sólo el TreeView.
>>
>>Un formulario normal (no jerárquico) podría tener un Grid en la mitad de arriba del formulario (o en Page1 de un PageFrame - esto depende, en parte, del espacio disponible), y campos de edición en la mitad de abajo del formulario (o en Page2).
>>
>>Un formulario jerárquico podría usar la misma filosofía - reemplazando, simplemente, el Grid por el TreeView. En el Click del nodo hay que seleccionar el registro y refrescar la pantalla - lo hice una vez, pero no recuerdo todos los detalles. Tampoco tengo el código fuente que creé hace algún tiempo. Hay que comenzar investigando el ejemplo que viene con Visual FoxPro.
>>
>>Se puede incluso mostrar tanto el grid como el TreeView, si se desea.
>>
>>¿Cuál es el tipo de relación? ¿Un padre - muchos hijos, como en el plan de cuentas? ¿O varios padres - varios hijos, como en materiales por artículo?
>>
>>Hilmar.
>
>Hola
>
>Mi caso seria varios padres- varios hijos, pero mi caso es un poco especial.
>Mi app es para constructores. Por alguna razon los ing. y arquitectos tienden
>a agrupar un proyecto de construccion en 'actividades'. Por ejemplo,El presupuesto de un proyecto seria algo asi: tenemos los insumos (materiales, mano de obra,maquinaria, etc) y las actividades (niveles jeararquicos)(A, B, C, D), una vez que se ha definido los insumos para el proyecto, el constructor establece las actividades de tipo A (por ejemplo, una pared, la
>pared esta compuiesta de ciertos materiales, y utiliza ciertas herramienstas, etc [la actividad A solo puede tener insumos]). Una vez que
>haya finalizado de definir este tipo de actividad se realiza la actividad
>tipo B, esta puede estar compuesta de insumos y de actividades tipo A (
>por ejemplo, un cuarto, ya que un cuarto esta compuesto de paredes que se
>podu haber definido como una actividad de tipo A) y asi
>sucesivamente hasta llegar a la actividad tipo D (la cual puede estar compuesta por cualquier tipo de actividad e insumos, por ejmplo, un edificio
>o casa es una actividad tipo D). Cuando se van definiendo las activiades no hay problemas, ya que estamos hablando de una pantalla padre-hijo (como si estuvieramos hablando de facturas, cabecera y detalles) aqui no se deben mostrar las jerarquias solo el registro hijo de mayor nivel. El problema viene cuando el usuario debe elaborar el presupuesto final, que es donde los
>los registro se pueden ver jerarquicamente (tambien se pueden modificar,
>borrar e insertar registros) aqui el arbol se muestra en un grid, pero no
>se muestran todas las actividades sino que las actividades de mas alto nivel
>elaboradas hasta ese momento.
>En realidad no hay problemas en definir la relacion padre-hijo, el problema
>es desplegar los registro segun su jerarquia. Me han dado varias respuestas
>acerca de como definir el indice pero creo no toman en cuenta ciertos detalles que involucran expresiones string que esten compuestas por numeros.
>Creo que tal vez tendre que usar un procedimiento recursivo que me
>ayude a mostrar el orden requerido, aunque prefiriria establecer una expresion de indice que me estableceria el orden.
>Creo que de la recursion no me salvare.
>Muchas gracias, todas sus sugerencias son bien recibidas
>
>Roman Suazo
>
>Ps. No se como encontrar al foro en español

Leí tu mensaje algo a la rápida, pero me parece que la situación es similar que la de mis artículos, que contienen materiales.

Tengo una tabla de artículos, con todo desde la materia prima, hasta el artículo terminado (y pasando por artículos intermedios, en varios niveles).

Tengo otra tabla para la composición (Art. A contiene Art. B), con los dos punteros correspondientes a la tabla de artículos.

Mi sistema no muestra información en forma jerárquica - los usuarios ven todos los "materiales" para un artículo, en un solo nivel. Sin embargo, en algunos informes se hace la "explosión de materiales" - descomponer los artículos en materiales, si algún material es de tipo intermedio, volver a reemplazarlo por sus respectivos materiales, etc.

Creo que eso es bastante similar a la situación de cálculo de costos para constructores.

Para mostrar información en este caso hay varias opciones. Por ejemplo, se puede mostrar un solo nivel, y tener un botón para abrir otra instancia de la pantalla, y ver el siguiente nivel.

Otra posibilidad es usar un treeview.

Otra posibilidad es mostrar la información en forma jerárquica, pero sólo en los informes. Para este fin, habría que crear un archivo texto, o un DBF, o algo por el estilo, con la información requerida.

Espero que esto sea de ayuda.

Hilmar.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
Previous
Reply
Map
View

Click here to load this message in the networking platform