Mecanizado de pieza, te odio

Llevo unos días más gruñón y contestón que de costumbre. Las razones son, principalmente, dos. La primera es que estoy incubando algo: me duele la garganta, me zumban los oídos… veremos mañana como me levanto. La segunda es que estoy atascado con la aplicación que ando haciendo para fábrica.

El jefe decidió este verano dos cosas: la primera es que había que hacer una base de datos de lo que fabricamos para poder sacar unas órdenes de fabricación en condiciones, gestionar nuestros productos, control de stock y lo que se tercie, que las hojas manuscritas al final se pierden o de tantas tachaduras y enmiendas no se entienden. Y más teniendo en cuenta que anda reduciendo plantilla y, claro, si echa al responsable de tal colección la llevamos clara porque es él quien sabe cómo se hace cada pieza.

La segunda cosa que decidió el jefe es que me encargara yo del asunto. Sin quejas por mi parte, porque así practico y le doy caña a Visual Basic. Llevo dos meses muy entretenido dando caña a los datasets. Este julio estuve preparando las especificaciones (no las hice bien, para variar) y documentándome sobre LINQ to SQL.

El problema se ha presentado con una parte mal desarrollada en el planteamiento previo que se ha traducido en un marrón que no sé por dónde cogerlo y me está haciendo la semana imposible: los mecanizados de la pieza. Cada pieza que componga un mueble tendrá sus operaciones de mecanizado. De las conversaciones con el responsable de fábrica y de las pocas fichas de mecanizado que se hicieron años a (en otro intento de racionalizar el tema) saqué unas conclusiones erróneas e hice la base de datos en función a ellas. Primer problema gordo. Dicho en cristiano, no había contado con el taladrado (diámetro de broca y profundidad del taladro; para la posición de los mismos, está el plano de la pieza, pero es importante saber si el taladro es pasante o no, por ejemplo) ni otros posibles mecanizados que requieran campos propios.

Tras romperme la cabeza, decidí que podía aprovechar la base de datos tal cual, pero presentando al usuario controles e información distintas según el tipo de mecanizado. Por ejemplo, si es un corte, el extra de medida que tenemos que dar a la pieza en bruto y las dimensiones (normalmente largo y ancho) a las que afecta. Si es un taladrado, el diámetro de la broca y la profundidad del mismo. Si entra en CNC, si va a medidas exactas o no… De momento tengo tres tipos de mecanizado (cuatro, pero el ranurado se fusionará con el taladrado) que han dado lugar a cuatro usercontrols y un usercontrol para el caso general (cuando dé de alta los dormitorios Cerezo, que me servirán de prueba general, veremos si me vale con eso o no). Luego he creado una interface para todos estos controles de usuario para que su gestión sea más fácil en el formulario.

Así que ahora tengo que controlar qué control de usuario muestro según el tipo de mecanizado de que se trate. Supongo que mostrando los distintos tipos de mecanizado en un combo y controlando el SelectedIndexChanged me valdrá…

Un problema añadido es el orden del mecanizado. Cada operación de mecanizado va cuando le toca y si cambio el número de orden de una, tendré que ajustar el resto. Es tan obvio y estúpido que… lo pasé por alto.

Y luego está el tema de decidir con qué trabajo en el formulario, si con la DataTable correspondiente a MecanizadoDePieza o con la DataTable de la vista que uso en el formulario de Piezas. Ayer dediqué un rato a hacer pruebas sobre esto último, tal y como comenté.

Así que esa es la razón por la que esté tan puñetero estos días: estoy cabreado conmigo mismo, por inútil, y como tengo la garganta tocada y hace frío para ahogar las penas en cerveza fresquita, me pongo a chinchar y gruñir (acabo de soltar “Paparruchas” en el foro, malo, malo).

Juro que cuando llegue a la parte de muebles, usaré un asistente para las altas y modificaciones. Un asistente, con siguiente, siguiente, siguiente. Por Ese Noopy que lo hago.

Deja un comentario