Citar:
Parece bastante claro que la idea de poner los dos datechooser en un tabstrip no me vale.
Eso no lo entendiste, seguramente porque lo leiste con demasiada prisa. Lo que sugerí fue que tal vez podrías colocar el datechooser fuera del tabstrip.
Bien, en el resto del mensaje me tomo el trabajo de responder intentando ser minucioso para evitar ambigüedades, por lo tanto, pido que se lea con atención.
De todos modos, veo que aún no es claro mi planteo. La cuestión no es que tu pregunta no fuera precisa, de hecho fue muy concreta y luego aclaraste un poco más lo que querías hacer.
No obstante, sigue habiendo un problema que no te atañe exclusivamente sino más bien lo contrario, es decir, es un problema general. Si lo analizas un poco, verás que tus preguntas están dirigidas a evacuar dudas puntuales sobre el uso de
gambas, y eso parece a todas luces ser lo adecuado.
Pues bien, generalmente lo es... pero no siempre.
Cuando se escribe un programa lo que se busca es solucionar un problema, ese problema nada tiene que ver con el lenguaje
gambas (de hecho generalmente podría escribirse tal programa en casi cualquier lenguaje de programación).
Cuando se analiza el problema que se quiere resolver, el enfoque del análisis se centra en el dominio del problema, por ejemplo si escribes un programa para realizar liquidación de salarios, emergerán conceptos desde el dominio del problema como: empleado, antigüedad, categoría, etc.
El diseño (que es independiente del lenguaje de programación que se utilice) consiste en modelar la solución tomando como base los conceptos que aparecieron al analizar el dominio del problema.
Cuando digo que no conocemos el problema a solucionar, me refiero a que nunca explicaste cuál era el problema que tu programa (o una parte de tu programa) debía resolver, es decir, lo que se supone que tu programa debe hacer desde la perspectiva del usuario.
Si alguien postea una pregunta como:
¿podría alguien explicarme como se hace en
gambas para serializar un objeto?
es claro para un programador que lea el mensaje que, con mucha probabilidad, quien pregunta conoce el paradigma de objetos, que tenga experiencia programando en otro lenguaje (como Java, C#, u otros) y que la respuesta deba ceñirse a responder exactamente a lo que se pregunta.
Si por el contrario se pregunta algo como:
¿cómo hago en
gambas para disponer del valor de una variable en x formularios?
un programador que lea el mensaje sabrá que quien pregunta está aprendiendo a programar o que suele escribir pequeños programas de forma ocasional (sin ser programador) y que su respuesta puede ceñirse exactamente a lo que se preguntó o tal vez sea necesario pedir más información sobre el problema que se quiere resolver (el del usuario) para estar en condiciones de sugerir una solución.
¿Por qué? Porque con alta probabilidad lo que se intenta hacer se podría realizar más fácilmente de otro modo, modificando el diseño y para ello hay que conocer el dominio del problema.
Entonces, a veces ser demasiado concreto y escueto al formular una pregunta reduce drásticamente las posibilidades de obtener respuestas que muestren diferentes soluciones que serían enriquecedoras.
¿Cuándo puede suceder esto? Con mayor probabilidad cuando no se dominan cabalmente las disciplinas involucradas en el desarrollo de software (cuando no se conoce bien o se está aprendiendo un lenguaje, cuando no se aplica una metodología de desarrollo, cuando no se conoce o se está aprendiendo sobre análisis y diseño de software).
Como impacto colateral suele suceder que las respuestas no son del todo atinadas y la pregunta inicial requiere la intervención de varios foristas y varias respuestas hasta lograr encaminar la cuestión. Es decir, que el thread pierde utilidad para el resto de la comunidad porque para comprender la pregunta y obtener respuestas adecuadas debe invertirse demasiado tiempo en leer una cantidad excesiva de mensajes.
La sugerencia que hago es que ante este tipo de situaciones quien pregunta debería enunciar la pregunta más o menos así:
Estoy escribiendo un programa de "tal tipo" y al querer hacer "tal cosa", me encuentro con "tal problema". Pensé que podría resolverlo "haciendo esto", pero al tomar este camino me encuento con "este otro inconveniente".
"tal tipo": gestión administrativa o contable, punto de ventas, grabación de cd, catalogación de archivos, conversión de formatos de video, procesador de textos, graficador de funciones, etc.
"tal cosa": realizar un consulta a la base de datos, generar un informe, presentar un resumen de información en pantalla que incluye..., imprimir un conjunto de datos que incluye..., etc.
"tal problema":
gambas me devuelve el mensaje de error X, no sé cómo obtener los datos de..., el valor de la variable X no es el que esperaba (yo esperaba que fuera Y), no obtengo el resultado que quiero (el resultado que quiero es X) y no encuentro el problema por ello les muestro el código de esa rutina, etc.
"haciendo esto": escribir una nueva rutina o formulario, modificando el código de este modo, utilizando este control, etc.
"este otro inconveniente": otro problema cualquiera sea.
Saludos cordiales.
Zaragoza
Foro 
