Maintenance of Dialog Screens under VC 2010 R3

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

Hi ,

There is no support for maintaining Dialog Screens in Visual COBOL R3.

You should continue to use Net Express (V5.1) for this.

Regards
David

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

I am in the process of converting all of the UI from a Dialog system to VCR3. I am a fluent dotnet developer but know nothing about Dialog. Is there a best practice for creating an intermediate layer to use the existing cobol logic while replacing all of the Dialog system? It would seem that since the Dialog system is very tightly layerd into the code, that this is not easy. Are there examples on the best way to do this?

I have managed to replace a simple screen but the way i did it was more of a hack than a good practice. i am just looking for what others do.

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

I am in the process of converting all of the UI from a Dialog system to VCR3. I am a fluent dotnet developer but know nothing about Dialog. Is there a best practice for creating an intermediate layer to use the existing cobol logic while replacing all of the Dialog system? It would seem that since the Dialog system is very tightly layerd into the code, that this is not easy. Are there examples on the best way to do this?

I have managed to replace a simple screen but the way i did it was more of a hack than a good practice. i am just looking for what others do.

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

I am in the process of converting all of the UI from a Dialog system to VCR3. I am a fluent dotnet developer but know nothing about Dialog. Is there a best practice for creating an intermediate layer to use the existing cobol logic while replacing all of the Dialog system? It would seem that since the Dialog system is very tightly layerd into the code, that this is not easy. Are there examples on the best way to do this?

I have managed to replace a simple screen but the way i did it was more of a hack than a good practice. i am just looking for what others do.

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

Sorry but we have no published document on best practices for converting Dialog System applications to WinForm or WPF applications that I know of.

There is no one-to-one relationship between screensets and forms and the logic issues are largely application dependant, such as if you use ActiveX controls and Control programs etc. in your screenset.

For any customers that have done this conversion already we would love to hear of your experiences, both bad and good...

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

Just a follow up, is there anyone out there who is using Dialog that are in need of converting over to VCOBOL?
I am thinking of coming up with some standards for this myself but being new to the COBOL language, it would be nice for some assistance. I am a seasoned .Net developer but putting me into COBOL with Dialog thrown on top of it, and only a license for VC (i don't have NetXpress or Dialog to see how these work), i find myself at somewhat of a loss.

Any assistance would be greatly appreciated.

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

Just a follow up, is there anyone out there who is using Dialog that are in need of converting over to VCOBOL?
I am thinking of coming up with some standards for this myself but being new to the COBOL language, it would be nice for some assistance. I am a seasoned .Net developer but putting me into COBOL with Dialog thrown on top of it, and only a license for VC (i don't have NetXpress or Dialog to see how these work), i find myself at somewhat of a loss.

Any assistance would be greatly appreciated.

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

I don't personally use the dialog system, but we have almost 2,000 screen sets that ship with our product. Each software house that uses dialog could use it in a different way.

Some developers might have :

very simple diaog screens
simple dialog screens with OCX controls
Complex dialog screens with validation code
Complex dialog screens with validation code and callouts
Dialog screens with use of the GUI class library

and these are just some of the combinations.

Generally screen sets use something called the Data Block, this Data block is the data passed between screet set and COBOL program and is normally in the form of a copy book or an include file. This copy book is then compiled into the screen set and the main driving COBOL program.

The dialog system as the option of exporting a screen set to a .IMP file....this is a text file that you could parse using C# or Visual COBOL. This .IMP file is probably going to be the method you'll end up using to move your way forward.

This .IMP file (I strongly recommended all Dialog developers create them), contains the complete structure of the screen set (When you corrupt a screen set you could recover it by importing the .IMP file), the type of window, sizes, and any validation code or procedures you need to branch too.

This is a snipped.

Object WIN-MAIN
Type WINDOW
Parent DESKTOP
Start (344,1268)
Size (2256,488)
Display "SMS Category Maintenance"
Style SIZE-BORDER TITLEBAR SYSTEM-MENU MAXIMIZE
Icon "my-icon"
Dialog CASE(ON)
Event GAINED-FOCUS
MOVE-OBJECT-ID $WINDOW S-CUR-WIN-DBOX ;
*
End Event # GAINED-FOCUS
Event CR
*
End Event # CR
Event WINDOW-CREATED
IF= ADD-CHG "A" NEW-CCLS ;
IF= ADD-CHG "C" CHG-FR-BROWSE ;
*
*
End Event # WINDOW-CREATED
Event CLOSED-WINDOW
BRANCH-TO-PROCEDURE CANCEL-PROC ;
End Event # CLOSED-WINDOW
Event ESC
BRANCH-TO-PROCEDURE CANCEL-PROC ;
*
End Event # ESC
Procedure GAIN-FOCUS
*
* Re-read all items to refresh list box
*
End Procedure # GAIN-FOCUS
Event USER-EVENT
BRANCH-TO-PROCEDURE CHECK-OTHER-EVENTS ;
*
End Event # USER-EVENT
End Dialog
End Object #WIN-MAIN

In the past if we have had to make a global change to lets say a button size or and entry box size, we've been able to do this programatically by changing the .IMP file and then re-importing them to recreate the screensets.

For me, our environment is probably one of the most complex, we have screen sets that are controlled not only by calls to the GUI class library but many winapi's too.

I think VC 2010 R3 or R4 are going to present intersting times for any software hosue using the dialog system, I'm hoping in the near future to see if I can get a hybrid system to work, so that would be R4 and dialog.

Let me know how you get on.

Neil

[Migrated content. Thread originally posted on 14 April 2011]

I know Dialog screens do not directly convert to the .Net framework but is it possible to maintain the Dialog screens in native COBOL using Visual COBOL 2010 R3?

I don't personally use the dialog system, but we have almost 2,000 screen sets that ship with our product. Each software house that uses dialog could use it in a different way.

Some developers might have :

very simple diaog screens
simple dialog screens with OCX controls
Complex dialog screens with validation code
Complex dialog screens with validation code and callouts
Dialog screens with use of the GUI class library

and these are just some of the combinations.

Generally screen sets use something called the Data Block, this Data block is the data passed between screet set and COBOL program and is normally in the form of a copy book or an include file. This copy book is then compiled into the screen set and the main driving COBOL program.

The dialog system as the option of exporting a screen set to a .IMP file....this is a text file that you could parse using C# or Visual COBOL. This .IMP file is probably going to be the method you'll end up using to move your way forward.

This .IMP file (I strongly recommended all Dialog developers create them), contains the complete structure of the screen set (When you corrupt a screen set you could recover it by importing the .IMP file), the type of window, sizes, and any validation code or procedures you need to branch too.

This is a snipped.

Object WIN-MAIN
Type WINDOW
Parent DESKTOP
Start (344,1268)
Size (2256,488)
Display "SMS Category Maintenance"
Style SIZE-BORDER TITLEBAR SYSTEM-MENU MAXIMIZE
Icon "my-icon"
Dialog CASE(ON)
Event GAINED-FOCUS
MOVE-OBJECT-ID $WINDOW S-CUR-WIN-DBOX ;
*
End Event # GAINED-FOCUS
Event CR
*
End Event # CR
Event WINDOW-CREATED
IF= ADD-CHG "A" NEW-CCLS ;
IF= ADD-CHG "C" CHG-FR-BROWSE ;
*
*
End Event # WINDOW-CREATED
Event CLOSED-WINDOW
BRANCH-TO-PROCEDURE CANCEL-PROC ;
End Event # CLOSED-WINDOW
Event ESC
BRANCH-TO-PROCEDURE CANCEL-PROC ;
*
End Event # ESC
Procedure GAIN-FOCUS
*
* Re-read all items to refresh list box
*
End Procedure # GAIN-FOCUS
Event USER-EVENT
BRANCH-TO-PROCEDURE CHECK-OTHER-EVENTS ;
*
End Event # USER-EVENT
End Dialog
End Object #WIN-MAIN

In the past if we have had to make a global change to lets say a button size or and entry box size, we've been able to do this programatically by changing the .IMP file and then re-importing them to recreate the screensets.

For me, our environment is probably one of the most complex, we have screen sets that are controlled not only by calls to the GUI class library but many winapi's too.

I think VC 2010 R3 or R4 are going to present intersting times for any software hosue using the dialog system, I'm hoping in the near future to see if I can get a hybrid system to work, so that would be R4 and dialog.

Let me know how you get on.

Neil