|
Añadir más controles a PowerCOBOL v3
Amigos, he estudiado un poco el tema, de cómo se agregan los controles que vienen en el pack de Power 3. Básicamente, en el registro hay lo siguiente:
En la carpeta Include:
En la clave Library:
En la clave Parts:
Y en la clave Options:
En definitiva, para la mayoría hay:
No sé cómo se conectan los controles en los IDE-s, pero todo esto me lleva a pensar que se trata de conexión bastante "clásica". He intentado añadir COMCTL32.DLL pero hay varios problemas. Primero, las antiguas DLL de Windows 98 no valen porque hacen referencias a rutinas en Kernel32.dll que ya no están disponibles en las nuevas OS. Otro problema es que no tengo un juego DLL + LIB acorde uno al otro. Y tercer problema, es que hay que escribir ficheros OCB que correspondan. He entendido cómo se escriben, pero no tengo tiempo de pegarme con ello. Lo que me falta es saber cómo se conecta el fichero OCB con el control en sí. Y necesito que alguien me eche una mano escribiendo OCB-s (explicaré cómo va el tema más tarde). Claramente no hay garantías de que lo consigamos, pero si sale - sinceramente sería la hostia!!! :D :bien: |
Olá,
coincidentemente eu estava estudando os OCBs para entender como eles funcionavam. Não consegui nenhuma documentação sobre a sintaxe usada, nem foi possível compilar um código semelhante. Posso escrever o código OCB, mas não tenho idéia sobre como compilar ou mesmo testar. Saludos, Emerson PS: Um controle que poderia agregar muito valor seria o de um GroupBox com clipping, como existe no PowerCobol 4 ou superior. Dá para criar áreas de scroll, relatórios e outras cositas más ;) |
Hola Eslopes, los OCB-s no hace falta compilarlos. Se deben guardar en la carpeta CLASS, para que el compilador los coja a la hora de compilar.
Los OCB-s de PC3 son diferentes a los de PC9 (que es el que uso normalmente). En este caso vamos a hablas del formato de los OCB para PC3. Mira, este es el powckbtn.ocb el cual corresponde a CheckButton (o CHECKn como se asigna en un Sheet): Código COBOL:
En este caso, tenemos herencia en una clase básica POWFUND que creo que viene en todos los OCB. Luego en CLASS SECTION tenemos las propiedades. FUNCTION MOVE equivale a SET, FUNCTION REFERENCE equivale a GET. REPLACING NAME BY contiene el nombre real de la función que está en la DLL. Entonces, según yo he entendido, en este caso cuando hacemos: Código COBOL:
Realmente por debajo se transforma en: Código COBOL:
En la DLL del nuevo control, debe hacer funciones equivalentes. Al menos es lo que he deducido hasta ahora. Seguramente hay otras funciones que no vemos aquí, pero por ejemplo el F5BBRUNS.DLL que es el que contiene los controles básicos, exporta algunas funciones más para todos los controles: Lista de todas las funciones que exporta dicha DLL: Código:
_CaGetCallUserProc@4 |
Olá,
ainda não está claro para mim como o PC3 vai reconhecer um novo OCB. Existe algum arquivo que indique que ele deve buscar o OCB quando estiver compilando ? Talvez um arquivo de propriedades. Outra dúvida, os métodos abaixo não possuem relação com as propriedades definidas no OCB. A mim parece que isto significa que estes métodos são fixos na F5BBRUN2.DLL. _xPowCkbtnChildWndProc@16 _xPowCkbtnGetClassHandle@0 _xPowCkbtnWndProc@16 Este métodos existem para os outros controles, sem que haja uma relação com os métodos descritos no OCB. Vou montar um OCB e colocar aqui no ForoCobol, mas acho que não será de grande valia sem primeiro entendermos se é possível realmente estender o PC3 (o que seria muito legal). Saludos, Emerson PS: uma outra alternativa seria reescrever o PC3 em C# para o .Net. Levaria algum tempo, mas poderíamos corrigir estas deficiências ;) |
Eslopes, aún no sé dónde se registra la relación con los OCB, pero en algún lado la hay seguro, así que la encontraré. De momento no hace falta hacer muchos OCB-s, simplemente quería que alguien se familiarice con ello para que pueda hacerlo en el futuro.
En cuanto a las funciones "_xPowXXXXX@n" esto lo sabía. Pero no es un problema, porque podemos hacer una DLL intermediaria en C++, donde definiremos estas funciones y cargaremos la DLL del control en la DLL intermediaria. Reescribir el compilador... Más bien el IDE... Me ha venido a la cabeza la idea, pero no sé cuanto tiempo nos va a costar hacerlo. Se podría aprovechar del compilador COBOL de Power3 y crear un nuevo IDE usando controles de MicroSoft, o BPL de Borland. El compilador de Power 9 compila TLB-s, pero no sé si tiene alguna obligación de ser TLB de ActiveX o cualquier TLB... Total, que tu idea me parece buena, pero se necesitaría más gente, y buen conocimiento del tema, y del compilador en sí (porque crear nuevo compilador es demasiado complicado, se necesita mucho tiempo...). |
Olá,
não é necessário fazer o compilador do zero. Existem pelo menos dois compiladores .net disponíveis (raincode e tomcat), além de que, o código do OpenCobol está disponível e pode (com mais esforço) ser recompilado para .Net. A IDE poderia ser baseada em Eclipse (ou Netbeans, a qual eu prefiro). O maior esforço seria desenvolver um parser e o GUI Designer que funcione como o Power (um evento é tratado com código Cobol apenas). Acho que podemos pelo menos gastar algum tempo estudando a idéia. Saludos, Emerson |
Eslopes, yo nunca he usado .NET así que no sé qué decirte en este caso. Yo preferiría en teoría BPL, o bibliotecas Win32 pero no un Framework. Pero bueno, es cuestion de verlo, en caso de .NET puede haber cosas que yo no sé y debería saberlas.
En cuanto al parser, creo que se podría hacer incluso en COBOL. El GUI Desinger ya va a ser dificil en COBOL, además no tengo ni idea de cómo se realizan... Creo que de momento mejorar el Power3 podría ser un comienzo para que en el futuro podamos hacer un IDE nuevo. ¿Qué opinas? |
Olá,
vou preparar alguns OCBs para o PC3 pois estou curioso para ver o que pode ser feito. Eu gostava muito do PC3 (usei em 1996 e 1997), especialmente pelo fato de que não precisava da instalação do runtime (como o power 4+) e pelo fato de que era muito rápido e adequado ao que eu precisava fazer naquela época. O problema é que o tempo passa e o PC3 ficou rapidamente defasado. O Power 4+ é praticamente outro produto. Graças ao uso de ActiveX e OO expandiu muito, mas também já ficou obsoleto. Voltar ao PC3, mas desta vez fazendo com que ele produza um código binário moderno, capaz de usar a vasta biblioteca de classes do .Net é algo que me atrai muito. Saludos, Emerson |
2 Archivos Adjunto(s)
Eslopes, mi idea es que tengamos la posibilidad de hacer programas modernos precisamente portables! ActiveX necesita ser registrado con derechos de administrador, es lo que no me gusta de él. Pero no entiendo por qué dices que quedó obsoleto? Depende del tipo de aplicación que quieres desarrollar. También no sé qué ventajas aporta realmente el .NET en caso de aplicaciones business (que es lo que hacemos los coboleros).
Sincermanete, los controles de PC9 + algunos OCX de terceros yo he hecho aplicaciones muy modernas (viasualmente). No sé si es a la parte visual a lo que te refieres con obsoleto. Los IDE-s de Borland (ahora ya Embarcadero) son muy buenos, para mí son mejores que Visual Studio. Y las clases VCL son muchas y abordan todo lo que se puede necesitar. Además, todo va incluído en el *.EXE (linkeado), y no hay dependencia ninguna de Framework instalado. Creo que Objective Cobol estaba hecho con el IDE de Borland, no he conseguido descargarlo (no lo encuentro en ningun lado). En definitiva, la idea para mi es modernizar y facilitar el GUI, manteniendo las ventajas de COBOL (ficheros RMKF indexados y etc), y que se compile en standalone executable con static run-time. |
Olá,
o que chamo de obsoleto: 1. Incapacidade de lidar com network (Web Services SOAP/REST, Sockets, Remote Method Invocation etc) 2. Dificuldade para lidar com XML (MSXML sofre do mal do chamado DLL Hell, diferentes versões na mesma máquina pelo Internet Explorer frequentemente entram em conflito e fazem aplicações pararem de funcionar) 3. Dificuldade de lidar como host de linguagens script (automação). Este recurso é simplesmente genial. Fiz um exemplo com PowerCOBOL e VBScript (Adding script support to PowerCobol applications ). Muita coisa é possível, mas é complicado passar objetos do Power para a linguagem script para que esta possa manipular o mesmo. Isto dificulta a implementação de Automation (criar Macros, por exemplo) que facilitam a vida do usuário 4. Dificuldade para lidar com mensageria (MSMQ). Não raro dependemos de bibliotecas de terceiros. 5. Impossibilidade de se criar modules/portlets para portais (ex: Dotnetnuke). Isto é uma fonte de frustração para mim, particularmente. Eu pretendia usar o DNN como estrutura de portal para aplicações Cobol para Web, mas não é possível com o Fujitsu Cobol for Windows. 6. Reutilização de componentes .Net (assinatura digital, grids inteligentes, gauges, componentes que consomem web services e um longo etc) 7. Uso do .Net Framework (runtime padrão Microsoft), que vem instalado nas versões do Windows desde o Vista/Windows 7. Muitos OCXs não funcionam com o Power por causa das estruturas de dados usadas. Isto é eliminado no .Net. É possível criar aplicações .Net para mobile (incluindo iOS e Android). A tecnologia do Power é Microsoft COM que só funciona no Windows. Por fim, a class library built in do .Net economiza tempo e dinheiro. Além destas ainda existem as criadas e distribuídas pelos desenvolvedores: Código:
Ajax |
| La franja horaria es GMT +2. Ahora son las 14:46. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.