Highlighted
New Member.
2299 views

Maintenance of Dialog Screens under VC 2010 R3

Jump to solution

[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?
0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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

View solution in original post

0 Likes
6 Replies
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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.
0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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...
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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.
0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Maintenance of Dialog Screens under VC 2010 R3

Jump to solution
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
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.