|
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 |
Olá,
selecionei a DLL MSXML.DLL que vem com o Windows (desde XP). Criei o seguinte OCB Código COBOL:
Estou sugerindo o nome de método do Power abaixo XPOWIXMLDOMDOCLOADXML Este método deverá substituir a chamada do método, seguindo o exemplo: Código COBOL:
deve resultar na compilação em : Código COBOL:
Alguns problemas que vejo: Onde será definido XPOWIXMLDOMDOCLOADXML ? Quem gera o código final ? O power? Como inserir o objeto MSXML na ventana "Item box" do Power? Saludos, Emerson |
Eslopes, la mayoría de las cosas que dices yo nunca las he necesitado. También creo que no es correcto exigir a un entorno ser "multitarea". En mi opinión, esta globalización no es buena, porque finalmente las herramientas dejan de ser fuertes en su perfil y se convierten en algo muy pesado y totalmente superficial. Se pierde contacto con la programación verdadera.
Cita:
Cita:
En fin, en mi opinión si se hace una WEB, se debe hacer en entorno WEB y no en COBOL. Otra cosa es que me gusta el código "nativo" para evitar incompatibilidades en el futuro. Mira los controles propios de Power 3 aún funcionan en Windows 7. Los Frameworks cada vez se hacen más grandes y esto supone mayor problema de compatibilidad y de bugs. Los VCL se basan en código "nativo", y proporcionan un montón de posibilidades! No sé si todo lo que tu describes, pero hay muchísimos controles incluidos Sockets-TCP/IP, Grids y etc. Echale un vistazo: VCL Components| Windows UI Controls | Konopka VCL Components Categories Index - RAD Studio Bueno, al final nos hemos ido a un tema muy amplio abandonando el tema de inicio. Qué hacemos con el Power 3? Intentamos ampliarlo o no? ;) |
Olá,
nenhum comentário sobre o OCB? Saludos, Emerson |
Eslopes, no había visto tu respuesta porque te había contestado justo al mismo tiempo.
A ver, el MSXML.DLL no vale, porque es un control ActiveX. Exporta las funciones siguientes:
Nos hacen falta Win32 Control Library (Windows), como COMCTL.DLL la cual exporta las funciones C/C++ como las siguientes:
Usar la COMCTL32.DLL es un poco pronto, porque tiene muchos controles dentro y nos vamos a morir escribiendo OCB-s, demasiado temprano. Hay que mirar un control separado, como MaskEdit o algo similar que sea sólo uno en la DLL. En cuanto al OCB, la parte REPLACING NAME BY "XPOWIXMLDOMDOCLOADXML" debe contener la función en la DLL. Es decir, las DLL de Power exportan funciones con nombres que empiezan con XPOW... Pero, si estuviéramos metiendo el COMCTL32.DLL, por ejemplo lara ImageList sería: Código COBOL:
Pero bueno, los OCB-s los necesitaremos después. De momento tengo que mirar: Cita:
|
Olá,
agora entendi a proposta. Acho que é possível montar um programa para gerar os OCBs para o caso do MSCOMCTL. Vou pesquisar um pouco e dou um retorno. Sobre XML, o governo brasileiro faz muitas exigências legais aos desenvolvedores de aplicações que emitem notas fiscais, forçando as aplicações a lerem e gerarem arquivos XMLs, consumir Web Services etc. Saludos, Emerson |
2 Archivos Adjunto(s)
Tengo 2 noticias, una buena y una mala :cerv: :D
La buena - ya he encontrado cómo va el tema. La mala - no se puede usar los controles directamente. Habrá que crear una DLL intermediaria en C/C++ la cual va a interactuar con los controles (por ejemplo Comdlg32.dll). ¿Por qué? Porque al indicar la DLL y la LIB correspondiente en el registro, nos salta el error que sale en adjuntos. Hurgando el PowerCOBOL he visto que lo que hace es cargar la DLL indicada y busca: Código CPP:
Donde lpName = "ITEMLIST". He mirado con el PE Explorer y he encontrado dentro de las DLL-s de controles que vienen con Power (en este caso F5BBRUN2.DLL) y me he encontrado con que tiene el segmento RC Data en el cual contiene un recurso llamado ITEMLIST (ver imagen en adjuntos). Mirando este recurso en Hex, casualmente he visto que hay una cadena con nulos y caracteres "raros", luego el identificador de la DLL (F5BBRUNS), y luego justamente los nombres de los OCB-s. Quedan cosas a investigar, pero estamos avanzando. |
Olá,
muy bueno. Talvez definindo uma classe C++ seja possível utilizar componentes visuais que possam ser adicionados a um form e que possuam uma caixa de diálogo para definir propriedades (como se fosse um componentes padrão do Power). Saludos, Emerson |
Eslopes, claro, es lo que pensaba hacer. Lo que pasa es que no sé nada de cómo de realizan los controles de este tipo. Antes hacía OCX para PC9, pero ActiveX es totalmente otra historia. Tengo que leer cierta documentación para aclararme con ello.
No diría que veo luz al final del túnel de momento :D Pero al menos ya estamos dentro del túnel! ;) |
:rofl::rofl::rofl::rofl::rofl::rofl:
|
1 Archivos Adjunto(s)
He instalado el Visual Studio... Antes hace unos años lo había instalado y no me ha gustado. Confirmo la opinión de antes, es el IDE menos intuitivo del mundo! Los IDE-s de Borland y ahora Embarcadero son mucho mejores! No me he enterado de nada del Visual Studio, vaya castaña...
Investigando un poco más el tema, he encontrado que los métodos, las propiedades y los eventos también residen escritos dentro de la DLL (imagen en Adjuntos). Entonces, yo creo que queda por investigar las Funciones que hay en la DLL comunes para todas las DLL las cuales son llamadas por PowerCOBOL de manera implícita. Luego, habrá que descifrar estas Funciones (con el decompilador seguramente), para encontrar funciones correspondientes en la DLL original (por ejemplo COMCTL32.DLL) y finalmente crear una DLL intermedia con los datos de RC DATA, y definir las funciones XPOW _POW comunes las cuales llamaran las Funciones originales de COMCTL32.DLL. Cuando lo consigamos, habrá que crear los OCB-s. Creo que cuando tenga la información necesaria, podemos comenzar por 1 sólo control (por ejemplo Button o Edit). Ah si, también hay que descubrir los caracteres raros que hay en RC DATA, qué significan y dónde se usan. |
Um arquivo .rc contém resources que são referenciados por uma aplicação. Me parece que aqui foram usados como uma espécie de estrutura de dados para o compilador. Talvez se descobrirmos a linha de comando usada para compilar o código powercobol, possamos entender melhor o proposito do rc data.
|
1 Archivos Adjunto(s)
Eslopes, ya he podido añadir un control a ITEMLIST. Claramente de momento no está mapeado a ninguna función por eso dice "Can't create item" :bien:
|
Excelente! Sinceramente duvidei que fosse possivel. Qual o proximo passo?
|
Cita:
|
Eslopes, estoy con la parte más chunga... Estoy mirando el PowerCOBOL y sus DLL-s decompiladas, para ver cómo carga los controles pero es muy dificil de seguir el código... Además, no sé y no he podido encontrar información de cómo se cargan los controles en modo Diseño (at Design time)... Me temo que esto va para largo. :(
|
Creio que o problema é que sendo um executável tão antigo, o PowerCOBOL 3 seja monolítico, ou seja, muita coisa deve hard-coded.
Andei estudando um pouco a IDE SharpDevelop. Existe um tutorial para adicionar uma linguagem de programação à IDE e portanto gerar código a partir dos controles padrões do .Net. Utilizando um Compilador Cobol .Net como o Raincode creio ser possível fazer um PowerCOBOL.Net, mas ainda não é certo. Saludos, Emerson |
Eslopes, el Raincode exige el Visual Studio Professional Edition, yo lo he probado con Expres Edition y no funciona... Además, como decía antes, yo nunca he usado .NET y es un historia muy diferente a la programación Win32. Para poder ensamblar algo hay que conocerlo bien. Yo creo que yo no podría montar un IDE de .NET, no conozco nada de ello.
En cuando al PowerCOBOL, yo uso varios decompiladores, pero el que mñas es el IDA Pro. Mis conocimientos de ASSEMBLER no son muy buenos, IDA genera código C a partir de ASM pero es aproximado, y las variables y las funciones se llaman de manera aleatoria (como sub_04FA54 o v01, v30, v52 etc...). Para entender bien cómo funciona, hay que obtener información de cómo lo hacen otros IDE como Visual Studio por ejemplo. Siempre queda la posibilidad de crear controles en dinámico vía WinAPI. Pero bueno, de momento intentaré seguir mirando y a lo mejor logramos injertar otro control al PowerCOBOL. |
Olá,
Raincode não é viável pois não implementa INVOKE. Vou procurar entre meus contatos quem possa nos ajudar com a estrutura do Power. Saludos, Emerson |
Olá,
após alguma investigação com o Boomerang e o Snowman (decompiladores) me parece que será muito complicado adicionar novos controles diretamente no Powercobol 3. O motivo é que o PC3 não é modular. A informação necessária para adicionar os controles a um form estão hardcoded no executável do próprio powercobol ou nas suas DLLs. Posso estar muito enganado, mas me parece praticamente impossível adicionar um novo controle sem ter acesso ao código fonte original do PC3 (o que é impossível no momento). Desejo boa sorte (e sinceramente espero que você consiga provar que estou errado), mas paro por aqui. Saludos, Emerson |
Eslopes, llevas razón. Pero imposible no es! Yo tengo código fuente C++ obtenida con el IDA Pro (decompilador). El PowerCOBOL.exe no hay que modificarlo, hay que determinar bien que funciones exportan las DLL y cómo registran clases. Es muy dificil, porque el como decía, el código decompilado no tiene nombres casi para nada (variables, funciones internas). Pero seguiré echando un ojo al tema cuando vaya tendiendo tiempo.
|
1 Archivos Adjunto(s)
Mira, estos son los fuentes resultado de la decompilación :piensa:
|
Eslopes, he preguntado a la gente más sabia que yo. A ver qué tal, a lo mejor tienen respuestas a lo que necesitamos.
|
Eslopes, parece que efectivamente no vale la pena... Es más fácil crear un IDE nuevo.
Sería un proyecto a largo plazo y voluntario, pero interesante. Habrá que determinar los criterios. Yo el .NET no lo conozco para nada, sin embargo conozco WinAPI. En este caso podríamos aprovechar, a lo mejor, del compilador gratuito de PowerCOBOL 3. La única pega que tiene es que no acepta CALLBACK o sea que no podemos hacer: Código COBOL:
Pero si de todos modos habrá que implementar un parser, creo que se podría reemplazar de alguna manera por la dirección física de MyPgm... ¿Qué opinas de todo esto? Por cierto, he encontrado un post en internet de un tío contando sobre el tema de un GUI Desinger: c++ - Creating a professional-looking (and behaving!) form designer - Stack Overflow No es tan fácil como creía yo... |
Cita:
Eslopes, he encontrado esto también: Cita:
|
o Wildcat é um abandonware. O desenvolvedor não levou o projeto à frente. .
Saludos, Emerson |
Cita:
retiro o que disse, o Wildcat Cobol está vivo e chutando!! (Live and kicking!) GitHub - sandydunlop/wildcat-cobol-compiler: Wildcat COBOL Compiler for .NET Talvez seja possível afinal criar um Powercobol for .Net ... |
Cita:
Bueno, qué te parece si lanzamos un mensaje a los foreros para que contribuyan, e intentemos montar une IDE con constructor GUI + Cobol (sea .NET o nativo)? Es una bella iniciativa la verdad. A ver cuánta gente se apunta. |
| La franja horaria es GMT +2. Ahora son las 13:58. |
Powered by: vBulletin, Versión 3.8.7
Derechos de Autor ©2000 - 2026, Jelsoft Enterprises Ltd.