Cobol - Creating a dialogBox dynamically...

Author

Creating a dialogBox dynamically...

Kellie Fitton

2005-04-11, 3:55 am

Hello Everyone,

If you like to create a dialogBox dynamically on-the-fly with COBOL
language, and without having to create and load a .DLL file during
runtime execution, simply compile and run this program that I have
put together as an example of using a memory template, to create an
empty dialogBox, then you can append to it several controls based
on the needs of the parent program, or perhaps on some events that
occurs within the main program.

This program was developed and tested with a Micro Focus COBOL
compiler (Net Express) and works fine like a charm. However, before
you create the .EXE file on your machine, simply include your own
library file (.DLL) that have a bitMap and an icon files into the
same folder, and please ensure to include the following library
files from your SDK library as well:
user32.lib, kernel32.lib, comctl32.lib, gdi32.lib.

Personally, I wanted to customize the skin of the dialogBox so I
can have a more sophisticated looking dialogBox, or perhaps to have
a professional image on the screen (Oracle database are notorious
of doing that). Unfortunately, I don't know how to do that, so, if
you find some sample programs or maybe a website link that shows
how to customize the skin and appreance of a dialogBox, please
please let me know. Regards. ;--))

Kellie Fitton.

*>---- My Cobol Sample Program --------<*

$set ans85 case align"8" defaultbyte"00" mfoo

identification division.
program-id. Dialogue.
author. Kellie Fitton (April 10, 2005).

Environment Division.
CONFIGURATION SECTION.

special-names.
call-convention 74 is WinAPI.

SOURCE-COMPUTER. IBM-ATX.
OBJECT-COMPUTER. IBM-ATX.

INPUT-OUTPUT SECTION.
FILE-CONTROL.

DATA DIVISION.
FILE SECTION.

working-storage section.
78 MyLibrary value "MyDLL.DLL" & x"0000".
78 IDCANCEL value h"0002".
78 WM-INITDIALOG value h"0110".
78 WM-COMMAND value h"0111".
78 WM-HELP value h"0053".
78 WM-CLOSE value h"0010".
78 WM-CTLCOLOREDIT value h"0133".
78 WM-SETFONT value h"0030".
78 WM-SETICON value h"0080".
78 WM-USER value h"0400".
78 BM-SETIMAGE value h"00f7".
78 TTM-ACTIVATE value WM-USER + 1.
78 TTM-ADDTOOL value WM-USER + 4.
78 TTM-SETTOOLINFO value WM-USER + 9.
78 ID-PUSHBUTTON1 value 100.
78 ID-PUSHBUTTON2 value 101.
78 ID-PUSHBUTTON3 value 102.
78 ID-PUSHBUTTON4 value 103.
78 ID-MYICON value 107.
78 ID-MYBITMAP value 102.

01 uint is typedef pic 9(9) comp-5.
01 int is typedef pic s9(9) comp-5.
01 HINSTANCE is typedef int.
01 HANDLE is typedef int.
01 LONG is typedef pic s9(9) comp-5.
01 ULONG is typedef pic 9(9) comp-5.
01 DWORD is typedef ulong.
01 SHORT is typedef pic s9(4) comp-5.
01 uns-short is typedef pic 9(4) comp-5.
01 data-pointer is typedef pointer value null.
01 LPTSTR is typedef usage data-pointer.
01 HFONT is typedef usage data-pointer.
01 ushort is typedef uns-short.
01 HWND is typedef int.
01 WORD is typedef uns-short.

01 COLORREF is typedef.
03 red pic x comp-5 value 0.
03 green pic x comp-5 value 0.
03 blue pic x comp-5 value 0.
03 leadByte pic x comp-5 value 0.

01 ClientRect.
03 xleft int.
03 ytop int.
03 xright int.
03 ybottom int.

01 RECT is typedef.
03 rleft int.
03 rtop int.
03 rright int.
03 rbottom int.

01 ToolInfo.
03 TOOLsize UINT.
03 TOOLflags UINT.
03 TOOLhwnd HWND.
03 TOOLuId UINT.
03 TOOLrect RECT.
03 TOOLhinst HINSTANCE.
03 TOOLtext LPTSTR.

01 InitCommonControlsEx is typedef.
03 dwSize DWORD value h"0000".
03 dwICC DWORD value h"0107".

01 POINT is typedef.
02 POINTx LONG.
02 POINTy LONG.

01 HELPINFO.
02 HELPSize UINT.
02 HELPContextType int.
02 HELPCtrlId int.
02 HELPItemHandle HANDLE.
02 HELPContextId DWORD.
02 HELPMousePos POINT.

01 DLGBoxTemplate.
02 DLGtemplateEX.
03 DLGver WORD value h"0001".
03 DLGsignature WORD value h"ffff".
03 DLGhelpID DWORD value h"0500".
03 DLGexStyle DWORD value h"0001".
03 DLGstyle DWORD value h"94c82ac4".
03 DLGcontrolItems WORD value h"0000".
03 DLGx short value h"0000".
03 DLGy short value h"0000".
03 DLGcx short value 295.
03 DLGcy short value 140.
03 DLGmenu WORD value h"0000".
03 DLGwindowClass WORD value h"0000".
03 DLGtitle pic x(64) value all x"00".
03 DLGpointSize WORD value 18.
03 DLGweight WORD value 700.
03 DLGitalic WORD value h"0000".
03 DLGcharSet WORD value h"0001".
03 DLGtypeFace pic x(32) value all x"00".
03 Filler pic x(02) value all x"00".

01 DLGBoxPointer procedure-pointer value null.
01 CommonControls InitCommonControlsEx.
01 MyColorRef COLORREF.
01 hNewFont HFONT.
01 hDC INT.
01 hIcon pic s9(9) comp-5 value 0.
01 hDLGBox pic s9(9) comp-5 value 0.
01 hStatic1 pic s9(9) comp-5 value 0.
01 hEdit1 pic s9(9) comp-5 value 0.
01 hStatic2 pic s9(9) comp-5 value 0.
01 hEdit2 pic s9(9) comp-5 value 0.
01 hStatic3 pic s9(9) comp-5 value 0.
01 hEdit3 pic s9(9) comp-5 value 0.
01 hStatic4 pic s9(9) comp-5 value 0.
01 hEdit4 pic s9(9) comp-5 value 0.
01 hTabControl pic s9(9) comp-5 value 0.
01 hTabFace pic s9(9) comp-5 value 0.
01 hImageBox pic s9(9) comp-5 value 0.
01 hButton1 pic s9(9) comp-5 value 0.
01 hButton2 pic s9(9) comp-5 value 0.
01 hButton3 pic s9(9) comp-5 value 0.
01 hButton4 pic s9(9) comp-5 value 0.
01 MyEdit1 pic x(32) value all x"00".
01 MyEdit2 pic x(32) value all x"00".
01 MyEdit3 pic x(32) value all x"00".
01 MyEdit4 pic x(32) value all x"00".
01 hInst pic s9(9) comp-5 value 0.
01 hPrevInstance pic s9(9) comp-5 value 0.
01 lpszCmdLine POINTER value null.
01 nCmdShow pic s9(9) comp-5 value 0.
01 hWinInit pic s9(9) comp-5 value 0.
01 MultiByteString pic x(256) value spaces.
01 WideCharString pic x(512) value spaces.
01 WideCharSize pic s9(9) comp-5 value 512.
01 hBitmap pic 9(9) comp-5 value 0.
01 hInstResource usage pointer value null.
01 hToolTip usage pointer value null.
01 ToolTipText pic x(32) value z"My Cobol ToolTip".
01 hPS pic s9(9) comp-5 value 0.
01 hSolidBrush pic s9(9) comp-5 value 0.

local-storage section.
01 MyData.
03 ls-mResult pic s9(9) comp-5.
01 ls-wParam.
03 ls-wId ushort.
03 ls-wNotifyParam ushort.

linkage section.
01 lnk-hWnd HWND.
01 lnk-iMessage UINT.
01 lnk-wParam.
03 lnk-wParam-LoWord pic 9(4) comp-5.
03 lnk-wParam-HiWord pic 9(4) comp-5.
01 lnk-lParam.
03 lnk-lParam-LoWord pic 9(4) comp-5.
03 lnk-lParam-HiWord pic 9(4) comp-5.

procedure division WinApi.
100-main-section.
call "cob32api"
end-call.
call "PC_WIN_INIT" using
hInst
hPrevInstance
lpszCmdLine
nCmdShow
returning hWinInit
end-call.
move length of InitCommonControlsEx to dwSize.
call WinAPI "InitCommonControlsEx" using
by reference CommonControls
returning Return-code
end-call.
call WinAPI "LoadLibraryA" using
by reference MyLibrary
returning hInstResource
end-call.
move spaces to MultiByteString
move "My Title..." to MultiByteString.
move x"00" to MultiByteString (12:1).
perform UnicodeText.
move WideCharString to DLGtitle.
move spaces to MultiByteString
move "Arial" to MultiByteString.
move x"00" to MultiByteString (6:1).
perform UnicodeText.
move WideCharString to DLGtypeface.
set DLGBoxPointer to entry "MyDLGBoxProc".
call winapi "DialogBoxIndirectParamA" using
by value hInst
by reference DLGBoxTemplate
by value h"0000" size 4
by value DLGBoxPointer
by value h"0000" size 4
returning hDLGBox
end-call.
call WINAPI "ShowWindow" using
by value hDLGbox
by value nCmdShow
returning Return-Code
end-call
call WinAPi "DestroyWindow" using
by value hDLGbox
returning Return-Code
end-call.
stop run.

UnicodeText Section.
if MultiByteString not = spaces
call winapi "MultiByteToWideChar" using
by value h"0000" size 4
by value h"00000001"
by reference MultiByteString
by value -1 size 4
by reference WideCharString
by reference WideCharSize
returning Return-Code
end-call
end-if.
exit section.

entry "MyDLGBoxProc" WinAPI using
by value hDLGbox
by value lnk-iMessage
by value lnk-wParam
by value lnk-lParam.
move 0 to ls-mResult
evaluate lnk-iMessage

when WM-INITDIALOG
call winapi "GetDC" using
by value hDLGbox
returning hDC
end-call
call winapi "CreateFontA" using
by value 18 size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value 700 size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0001" size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value 48 size 4
by reference "Arial" & x"0000"
returning hNewFont
end-call
call winapi "SetMapperFlags" using
by value hDC
by value h"0001" size 4
returning Return-Code
end-call
call winapi "ReleaseDC" using
by value hDLGbox
by value hDC
returning Return-Code
end-call
move 0 to red of MyColorRef
move 255 to green of MyColorRef
move 255 to blue of MyColorRef
call winapi "CreateSolidBrush" using
by reference MyColorRef
returning hSolidBrush
end-call
if hInstResource not = null
call WINAPI "LoadIconA" using
by value hInstResource
by value ID-MYICON size 4
returning hIcon
end-call
call winapi "SendMessageA" using
by value hDLGbox
by value WM-SETICON size 4
by value h"0000" size 4
by value hIcon
returning Return-Code
end-call
end-if
call winapi "CreateWindowExA" using
by value h"0080" size 4
by reference "tooltips_class32" & x"0000"
by reference x"0000"
by value h"80000003"
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hToolTip
end-call
if hToolTip not = null
call winapi "SetWindowPos" using
by value hToolTip
by value -1 size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0000" size 4
by value h"0013" size 4
returning return-code
end-call
initialize ToolInfo
move length of ToolInfo to TOOLsize
call winapi "GetClientRect" using
by value hDLGbox
by reference ClientRect
returning Return-Code
end-call
move xLeft to rLeft of ToolRect
move yTop to rTop of ToolRect
move xRight to rRight of ToolRect
move yBottom to rBottom of ToolRect
move 16 to TOOLflags
move hDLGbox to TOOLhwnd
move hInst to TOOLhinst
set TOOLtext to address of ToolTipText
call winapi "SendMessageA" using
by value hToolTip
by value TTM-ADDTOOL size 4
by value h"0000" size 4
by reference ToolInfo
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hToolTip
by value TTM-SETTOOLINFO size 4
by value h"0000" size 4
by reference ToolInfo
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hToolTip
by value TTM-ACTIVATE size 4
by value h"0001" size 4
by reference ToolInfo
returning Return-Code
end-call
end-if
call WINAPI "CreateWindowExA" using
by value h"0001" size 4
by reference "SysTabControl32" & x"0000"
by reference x"0000"
by value h"54002000"
by value 15 size 4
by value 8 size 4
by value 560 size 4
by value 250 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hTabControl
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "STATIC" & x"0000"
by reference "Data Entry1:" & x"0000"
by value h"50000000"
by value 42 size 4
by value 34 size 4
by value 80 size 4
by value 22 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hStatic1
end-call
call WINAPI "CreateWindowExA" using
by value h"00000200"
by reference "EDIT" & x"0000"
by reference MyEdit1
by value h"50810000"
by value 130 size 4
by value 30 size 4
by value 243 size 4
by value 26 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hEdit1
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "STATIC" & x"0000"
by reference "Data Entry2:" & x"0000"
by value h"50000000"
by value 42 size 4
by value 74 size 4
by value 80 size 4
by value 22 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hStatic2
end-call
call WINAPI "CreateWindowExA" using
by value h"00000200"
by reference "EDIT" & x"0000"
by reference MyEdit2
by value h"50810000"
by value 130 size 4
by value 70 size 4
by value 243 size 4
by value 26 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hEdit2
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "STATIC" & x"0000"
by reference "Data Entry3:" & x"0000"
by value h"50000000"
by value 42 size 4
by value 114 size 4
by value 80 size 4
by value 22 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hStatic3
end-call
call WINAPI "CreateWindowExA" using
by value h"00000200"
by reference "EDIT" & x"0000"
by reference MyEdit3
by value h"50810000"
by value 130 size 4
by value 110 size 4
by value 243 size 4
by value 26 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hEdit3
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "STATIC" & x"0000"
by reference "Data Entry4:" & x"0000"
by value h"50000000"
by value 42 size 4
by value 154 size 4
by value 80 size 4
by value 22 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hStatic4
end-call
call WINAPI "CreateWindowExA" using
by value h"00000200"
by reference "EDIT" & x"0000"
by reference MyEdit4
by value h"50810000"
by value 130 size 4
by value 150 size 4
by value 243 size 4
by value 26 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hEdit4
end-call
if (hEdit1 not = 0)
and (hEdit2 not = 0)
and (hEdit3 not = 0)
and (hEdit4 not = 0)
call winapi "SendMessageA" using
by value hEdit1
by value WM-SETFONT size 4
by value hNewFont
by value h"0001" size 4
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hEdit2
by value WM-SETFONT size 4
by value hNewFont
by value h"0001" size 4
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hEdit3
by value WM-SETFONT size 4
by value hNewFont
by value h"0001" size 4
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hEdit4
by value WM-SETFONT size 4
by value hNewFont
by value h"0001" size 4
returning Return-Code
end-call
end-if
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "BUTTON" & x"0000"
by value h"0000" size 4
by value h"50000080" size 4
by value 390 size 4
by value 25 size 4
by value 160 size 4
by value 160 size 4
by value hDLGbox
by value h"0000" size 4
by value hInst
by value h"0000" size 4
returning hImageBox
end-call
if hInstResource not = null
call winapi "LoadImageA" using
by value hInstResource
by value ID-MYBITMAP size 4
by value h"0000" size 4
by value 152 size 4
by value 152 size 4
by value h"0000" size 4
returning hBitmap
end-call
call winapi "SendMessageA" using
by value hImagebox
by value BM-SETIMAGE size 4
by value h"0000" size 4
by value hBitmap
returning Return-Code
end-call
end-if
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "BUTTON" & x"0000"
by reference "Push Button1" & x"0000"
by value h"50010001"
by value 35 size 4
by value 200 size 4
by value 105 size 4
by value 40 size 4
by value hDLGbox
by value ID-PUSHBUTTON1
by value hInst
by value h"0000" size 4
returning hButton1
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "BUTTON" & x"0000"
by reference "Push Button2" & x"0000"
by value h"50010000"
by value 170 size 4
by value 200 size 4
by value 105 size 4
by value 40 size 4
by value hDLGbox
by value ID-PUSHBUTTON2
by value hInst
by value h"0000" size 4
returning hButton2
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "BUTTON" & x"0000"
by reference "Push Button3" & x"0000"
by value h"50010000"
by value 305 size 4
by value 200 size 4
by value 105 size 4
by value 40 size 4
by value hDLGbox
by value ID-PUSHBUTTON3
by value hInst
by value h"0000" size 4
returning hButton3
end-call
call WINAPI "CreateWindowExA" using
by value h"0000" size 4
by reference "BUTTON" & x"0000"
by reference "Push Button4" & x"0000"
by value h"50010000"
by value 440 size 4
by value 200 size 4
by value 105 size 4
by value 40 size 4
by value hDLGbox
by value ID-PUSHBUTTON4
by value hInst
by value h"0000" size 4
returning hButton4
end-call
if hEdit1 not = 0
call winapi "SetFocus" using
by value hEDIT1
returning Return-Code
end-call
end-if
continue

when WM-CTLCOLOREDIT
move lnk-wParam to hPs
if hNewFont not = null
call winapi "SelectObject" using
by value hPS
by value hNewFont
returning Return-Code
end-call
end-if
if hSolidBrush not = 0
call winapi "SelectObject" using
by value hPS
by value hSolidBrush
returning Return-Code
end-call
call winapi "SetBkMode" using
by value hPS
by value h"0002" size 4
returning Return-Code
end-call
move 0 to red of MyColorRef
move 255 to green of MyColorRef
move 255 to blue of MyColorRef
call winapi "SetBkColor" using
by value hPS
by value MyColorRef
returning Return-Code
end-call
move 0 to red of MyColorRef
move 0 to green of MYColorRef
move 128 to blue of MyColorRef
call winapi "SetTextColor" using
by value hPS
by value MyColorRef
returning Return-Code
end-call
move hSolidBrush to ls-mResult
end-if
continue

when WM-HELP
call winapi "WinHelpA" using
by value hDLGbox
by reference
"C:\WINDOWS\HELP\WINHLP32.HLP" & x"0000"
by value h"000b" size 4
by value h"0000" size 4
returning Return-Code
end-call
continue

when WM-COMMAND
move lnk-wParam to ls-wParam
evaluate ls-wID

when IDCANCEL
call winapi "SendMessageA" using
by value hDLGbox
by value WM-SETICON size 4
by value h"0000" size 4
by value h"0000" size 4
returning Return-Code
end-call
call winapi "SendMessageA" using
by value hDLGbox
by value BM-SETIMAGE size 4
by value h"0000" size 4
by value h"0000" size 4
returning Return-Code
end-call
call winapi "ReleaseDC" using
by value hDLGbox
by value hPS
returning Return-Code
end-call
call winapi "DeleteObject" using
by value hNewFont
returning Return-Code
end-call
call winapi "DeleteObject" using
by value hSolidBrush
returning Return-Code
end-call
call WinAPI "EndDialog" using
by value hDLGbox
by value lnk-wParam
returning Return-Code
end-call
continue

when ID-PUSHBUTTON1
continue

when ID-PUSHBUTTON2
continue

when ID-PUSHBUTTON3
continue

when ID-PUSHBUTTON4
continue

when other
call WINAPI "DefWindowProcA" using
by value hDLGbox
by value lnk-iMessage
by value lnk-wParam
by value lnk-lParam
returning ls-mResult
end-call
end-evaluate

when WM-CLOSE
call WinAPI "EndDialog" using
by value hDLGbox
by value lnk-wParam
returning Return-Code
end-call
continue

when other
continue
end-evaluate
exit program returning ls-mresult.

end program Dialogue.

James J. Gavan

2005-04-11, 3:55 am

Kellie Fitton wrote:
> Hello Everyone,
>
> If you like to create a dialogBox dynamically on-the-fly with COBOL
> language, and without having to create and load a .DLL file during
> runtime execution, simply compile and run this program that I have
> put together as an example of using a memory template, to create an
> empty dialogBox, then you can append to it several controls based
> on the needs of the parent program, or perhaps on some events that
> occurs within the main program.
>
> This program was developed and tested with a Micro Focus COBOL
> compiler (Net Express) and works fine like a charm. However, before
> you create the .EXE file on your machine, simply include your own
> library file (.DLL) that have a bitMap and an icon files into the
> same folder, and please ensure to include the following library
> files from your SDK library as well:
> user32.lib, kernel32.lib, comctl32.lib, gdi32.lib.
>
> Personally, I wanted to customize the skin of the dialogBox so I
> can have a more sophisticated looking dialogBox, or perhaps to have
> a professional image on the screen (Oracle database are notorious
> of doing that). Unfortunately, I don't know how to do that, so, if
> you find some sample programs or maybe a website link that shows
> how to customize the skin and appreance of a dialogBox, please
> please let me know. Regards. ;--))

Congrats, plus the source that you sent me so that I can visually see
the Dialog Box. I'll reply later privately with some 'constructive
criticisms' - but let's see what else you get.

Do you want to translate your last paragraph :-). What exactly do you
want to skin ? Are you really asking how can I merge a Dialog with data
from a Database. If that's your question then within N/E :-

Menu Bar------>Tools-------->ESQL Assistant

Give the background some reading, but steps are, assuming use of MS
Access :-

1. Create your MS Database xxxxxx.mdb; although if you want to "play"
Micro Focus provides Sample1 and Sample2. If you installed ODBC/SQL as a
feature then these two mdb's should appear listed under the ODBC driver,
"System". Check out the ODBC through the Control Panel.

2. Once you have a Database 'attached' to the ODBC Driver then you can
use the ESQL Assistant above. Click on the DB you are interested in and
expand to show all tables contained therein. For each table you can now
generate a set of SQL Statements. Use the icon at the top to Copy/Paste
into your COBOL source the SQL statement you generated. Also for each
table use the ESQL feature :-

Auxiliary Code--->Host Variable Declaratives

This generates a three section copyfile :-

1. Field definitions for SQL - VARCHAR, INT etc.
2. Field definitions for COBOL - pic x(??) or pic x(4) comp-5 etc
for numerics
3. Field definitions for SQL NULLs

I extract #2 to keep it as a separate copyfile so that I can use it in a
File Edit Class and in the MyTable Class. I only need 1 and 3 in the
latter, because all my SQL is segregated into this one class per table.
(Don't have to do it that way - but that's the approach I took).

Same principle should apply if you are using any other DB software.
There's a pretty comprehensive on-line manual dealing with DBs.

If you are looking for a 'pattern' to display records from a DB - If you
like the Listview approach then in effect you have a 'collection'
containing the following. (In my case, *existing* records from the DB
are listed alpha ascending in a ListBox - from which the user can
choose. Note - any record 'adds, 'changes' or 'deletes' mean you have to
update the Listbox and do a 'refresh' display :-

1. Display Dialog and focus on Customer A/c # (Note - in my case I focus
on the Listbox but the user can select the empty Customer # to enter the
key, *supposedly" for a new record - if they choose a legit key THEN
display the *existing* record).

2. User enters zeroes/spaces - Quit
3. Otherwise PERFORM/CALL/INVOKE "Read-file" using key returning
detailed record or blank record.

4. Detailed - display and accept changes or DELETE

4a PB-OK - Changes made - check for validity - PERFORM/CALL/INVOKE
"rewrite/update"

4b. OK to delete ? PERFORM/CALL/INVOKE 'delete-record" using key

5. Blank new record - tab through accepting fields until done. (NB :
Once you have accepted/displayed a Customer # as legit - make it READ
ONLY - you don't want the user buggering around with the number,
otherwise he is going to send your program off into space and screw up
your file/DB !)

5a. Then allow user to 'jump' around fields correcting previous typos,
and of course any errors resulting from validity checks in 5b below.

5b. PB-OK - validity checks on new record - PERFORM/CALL/INVOKE
'write/insert-record"

6. PB-Cancel - ignore what has happened so far and display fresh screen
(dialog)

Jimmy

Robert Wagner

2005-04-11, 3:55 am

On 10 Apr 2005 17:56:44 -0700, "Kellie Fitton"
<KELLIEFITTON@YAHOO.COM> wrote:

Very nice code. I have a few nitpicks on style:

> SOURCE-COMPUTER. IBM-ATX.
> OBJECT-COMPUTER. IBM-ATX.

Leave them out. They don't do anything.
>
> INPUT-OUTPUT SECTION.
> FILE-CONTROL.
>
> DATA DIVISION.
> FILE SECTION.

Same.

> 78 MyLibrary value "MyDLL.DLL" & x"0000".

Change to 78 MyLibrary value z"MyDLL.DLL".

> call "cob32api"
> end-call.

Delete end-call. The only scope delimiters you need are end-if,
end-evaluate and end-perform.

> returning Return-code

Delete. That's what it does by default.

> end-if
> continue

Delete continue.

William M. Klein

2005-04-11, 3:55 am

And of course what Robert means <G>,

Is that *IF* you were coding to his coding standards, this is what HE would do.

Of the items that he points out, there is NOTHING wrong with how you have coded
them.

Personally, I would even argue that using

"MyDLL.DLL" & x"0000".

(which conforms to the ISO 2002 Standard *and* the "&" operator is in EVERY
X/Open conforming compiler)

is better than using a z-literal - which is available in Micro Focus and IBM -
but (as far as I know) no other compiler.

"continue" following an END-IF can be useful for "break-point" debugging, but in
MOST cases is "pretty useless".

Do *not* remove the "Data Division" header (if that is what RW meant) if you
have a Working-Storage (or Local-Storage) Section unless you want to create
source code that will compile with Micro Focus but NO other compiler that I know
of. (Removing "empty" section headers is reasonable, but doesn't really
accomplish anything except POTENTIALLY making it harder to add new sections
later on.)

Using scope-terminators with unconditional statements MAY prove beneficial when
doing future maintenance, but I agree they certainly do NOT add anything
"today". Having a scope terminator (End-Call) after an unconditional CALL
statement and immediately before a period (full stop) is particularly redundant
(he said redundantly <G> ) - but it does NOT hurt anything (unless it violates
YOUR "shop standard").

--
Bill Klein
wmklein <at> ix.netcom.com
"Robert Wagner" <spamblocker-robert@wagner.net> wrote in message
news:d2qj51ti4r5d6rqspgqoo3u4hko1is1ppn@
4ax.com...
> On 10 Apr 2005 17:56:44 -0700, "Kellie Fitton"
> <KELLIEFITTON@YAHOO.COM> wrote:
>
> Very nice code. I have a few nitpicks on style:
>
>
> Leave them out. They don't do anything.
>
> Same.
>
>
> Change to 78 MyLibrary value z"MyDLL.DLL".
>
>
> Delete end-call. The only scope delimiters you need are end-if,
> end-evaluate and end-perform.
>
>
> Delete. That's what it does by default.
>
>
> Delete continue.
>

Kellie Fitton

2005-04-11, 3:55 am

Charles,

this is just a simple program to demonstrate the use of the win32 API's
functions, which
is readily documented on the MSDN's website and in their SDK software.
The code is
pretty much straight forward and self explanatory. However, I did not
include the style
variables in my code just to keep it short and simple, beside, I used
the standard styles
for all the controls, which is avaiables in the windows.h and the
commctrl.h files.

Kellie.

Kellie Fitton

2005-04-11, 3:55 am

Robert,

I like to use the "end-call" and "returning Return-Code" clause for
two simple reasons:

1). End-call helps me to visualize the end of the call, thus I know
there is no more
arguments to follow after that.
2). Some times I need to debug and analyze the return-code --- so, its
there for me.

I tend to use the continue clause out of a habit, simply because, if I
use a window
message for example, with no cobol code to follow, the compiler would
raise a falg
unless I include the continue clause. For example:

WM-MOVE
continue

without the continue clause, I would get an error message from the
compiler.

Kellie.

Richard

2005-04-11, 3:55 am

> WM-MOVE
> continue

> without the continue clause, I would get an error message from the
compiler.

You shouldn't get an error message unless this is the last WHEN in an
EVALUATE, but you may get strange effects at run-time.

When two or more WHENs are contiguous they are treated as a if there
was an OR between them:

EVALUATE something
WHEN 'a'
code executed when value is 'a'
WHEN 'b'
WHEN 'c'
code executed when value is 'b' or 'c'
WHEN 'd'
CONTINUE
WHEN 'e'
code executed when value is 'e' only
END-EVALUATE

So a CONTINUE is necessary if you comment out the action code for a
value and leave the WHEN in.

Kellie Fitton

2005-04-11, 3:55 am

Richard,

if I comment the continue clause --- it causes more problems to other
statements in the
windows procedure, especially the Evaluate statement. Here is the error
message that
I get when there is NO continue clause in my windows procedure section.

Rebuilding C:\Unzipped\DIALOGUE\DIALOGUE.cbl
C:\Unzipped\DIALOGUE\DIALOGUE.cbl(749,31): * 14-S Invalid operand
C:\Unzipped\DIALOGUE\DIALOGUE.cbl(759,17): * 368-S Exception phrase
inappropriate
C:\Unzipped\DIALOGUE\DIALOGUE.cbl(767,17): * 368-S Exception phrase
inappropriate
C:\Unzipped\DIALOGUE\DIALOGUE.cbl(769,12): * 564-S A scope-delimiter
did not have a matching verb and was discarded.
Rebuild complete with errors

Kellie.

Kellie Fitton

2005-04-11, 3:55 am

Bill,

speaking of scope-terminators and end-performs, I was having problems
with this
particular cobol code in my windows procedure --- I could use your help
on this one,
does this coding style looks correct to you:

move zeros to Myhandle
perform until EXIT
if Myhandle = 5
exit perform
end-if
add 1 to Myhandle
add some numbers or some cobol code here
more cobol code
end-perform.

my program was hanging because of this perform statement --- the
program went into an
infinite loop, and never came back to planet earth again. Did I code
this perform statement
correctly??

Kellie.

Kellie Fitton

2005-04-11, 8:55 am

Jimmy,

to customize the skin of a dialogBox is simply to change its apprears
dramatically, it is
more than just slapping a bitMap image on its surface to hide the grey
color. You would
add more rounded and 3D buttons into the title bar to replace the
default system menu,
the corners of the dialogBox per se would be rounded as well to give it
the illusion of
being Floating on the screen. Also, each button would have a titleBar
with its own
property buttons for further menu selections and colour choices. The
titleBar can also
have toolBar buttons for more menu selections as well. Its very very
blase, you know.

Kellie.

Richard

2005-04-11, 8:55 am

move zeros to Myhandle
perform until EXIT
if Myhandle = 5
exit perform
end-if
add 1 to Myhandle
add some numbers or some cobol code here
more cobol code
end-perform.

The code _looks_ fine. A 'handle' though, is a refernce to an area of
data or an 'object', it shouldn't be modified. I know that you were
just using it as a random variable, but someone reading the code will
be

as to why you are using a 'handle'.

It may be that 'more cobol code' is changing the variable Myhandle by
using it as a return from a call so that it never gets to be = 5.

Richard

2005-04-11, 8:55 am

> if I comment the continue clause --- it causes more problems > to
other statements in the windows procedure,

If you comment out the CONTINUE in a WHEN and there are no other
statements in that WHEN then the next set of actions under the next
WHEN will be executed.

> Here is the error message that I get when there is NO continue
> clause in my windows procedure section.

This may be caused by the END-CALL, I can't see anything else that may
be doing it.

A scope delimiter should only be necessary if the conditional clause is
used in a statement. In the case of a CALL this is the ON EXCEPTION or
ON OVERFLOW.

CALL xxxx USING ...

is an imperitive statement and does not need an END-CALL, in fact it is
probably an error to have one.

CALL ....
ON EXCEPTION ....

is a conditional statement and _requires_ scope termination by a full
stop or an END-CALL.

Putting spurious END-~ scope terminators (as you have done) is a
mistake because it can lead to parsing errors or unexpected results (as
you seem to have found).

For example:

CALL "A" USING something
ON EXCEPTION
CALL "B" USING someerrorcode
END-CALL
DISPLAY "There was an error in calling A"

Kellie Fitton

2005-04-11, 3:55 pm

Hi Richard,

my understanding of an "end-call" clause is that it
is simply equivalent to a full stop which is a dot.
For example,

call "MyProgram".

is the same as

call "MyProgram"
end-call.

I downloaded a sample program from Micro
Focus's website that is called "CreateP", they
are coding the "end-call" as well.
here is the sample program from Micro Focus's
webSite:

$set ans85 mf defaultbyte"00" case constant INTCODE(0)

*----------------------------------------------------------------*
* CREATEP
*
*
*
* This example demonstrates the use of the Win32 API function
*
* call CreateProcess in order to execute a non-COBOL program
*
* from within a COBOL program. In this example, the Windows
*
* Text Editor NOTEPAD.EXE will be executed. The program will
*
* then wait until NOTEPAD has been exited at which point it
*
* will also exit.
*
*
*
* CreateProcess allows you to control how a program is started
*
* along with the parameters, the environment and the working
*
* directory that the new program should use.
*
*
*
* Parameters passed are as follows:
*
* 1. Application-name:
*
* Pointer to a null-terminated string that specifies the
*
* module to execute. The string can specify the full path
*
* and filename of the module to execute. The string can
*
* specify a partial name. In that case, the function uses
*
* the current drive and current directory to complete the
*
* specification. The Application-name parameter can be
NULL.*
* In that case, the module name must be the first white
*
* space-delimited token in the Command-line parameter.
*
*
*
* 2. Command-line:
* Pointer to a null-terminated string that specifies the
*
* command line to execute. The Command-line parameter can
*
* be NULL. In that case, the function uses the string
*
* pointed to by Application-name as the command line.
*
* If both Application-name and Command-line are non-NULL,
*
* Application-name specifies the module to execute, and
*
* Command-line specifies the command line. If Application-
*
* name is NULL, the first white space-delimited token of
the*
* command line specifies the module name. If the process to
*
* be created is an MS-DOS - based or Windows-based applica-
*
* tion, Command-line should be a full command line in which
*
* the first element is the application name. Because this
*
* also works well for Win32-based applications, it is the
*
* most robust way to set Command-line.
*
*
*
* 3. Process-attributes:
*
* This points to a structure which determines whether the
*
* returned handle can be inherited by child processes. If
*
* Process-attributes is NULL, the handle cannot be
*
* inherited.
*
*
*
* 4. Thread-attributes:
*
* This points to a structure which determines whether the
*
* returned handle can be inherited by child processes. If
*
* Process-attributes is NULL, the handle cannot be
*
* inherited.
*
*
*
* 5. Inheritance-flag:
*
* Indicates whether the new process inherits handles from
*
* the calling process. If TRUE, each inheritable open
handle*
* in the calling process is inherited by the new process.
*
* Inherited handles have the same value and access privil-
*
* eges as the original handles.
*
*
*
* 6. Creation-flags:
*
* Specifies additional flags that control the priority
*
* class and the creation of the process. For a full
descrip-*
* tion of these flags see the Windows SDK Help file and
*
* search under CreateProcess. The constants for these
values*
* can be found in winbase.cpy.
*
*
*
* 7. Environment-block:
*
* Points to an environment block for the new process. If
*
* this parameter is NULL, the new process uses the environ-
*
* ment of the calling process. An environment block
consists*
* of a null-terminated block of null-terminated strings.
*
* Each string is in the form: name=value. Because the equal
*
* sign is used as a separator, it must not be used in the
*
* name of an environment variable.
*
*
*
* 8. Current-directory:
*
* Points to a null-terminated string that specifies the
*
* current drive and directory for the child process. The
*
* string must be a full path and filename that includes a
*
* drive letter. If this parameter is NULL, the new process
*
* is created with the same current drive and directory as
*
* the calling process.
*
*
*
* 9. Startup-info:
*
* Points to a STARTUPINFO structure that specifies how the
*
* main window for the new process should appear. This
struc-*
* ture is defined in winbase.cpy.
*
*
*
* 10. Process-info:
*
* Points to a PROCESS_INFORMATION structure that receives
*
* identification information about the new process. This
*
* structure is defined in winbase.cpy.
*

*----------------------------------------------------------------*
id division.
program-id. createp.
special-names.
call-convention 74 is staticWINAPI.
data division.
working-storage section.
copy "miniwin.cpy".
copy "wintypes.cpy".
copy "winuser.cpy".
copy "winbase.cpy".
78 PROGRAM-NAME value
"CREATEP".
01 startup-info STARTUPINFOA.
01 process-info PROCESS-INFORMATION.
01 ws-okay BOOL.
01 ws-app-return-code DWORD.
01 executable-and-command-line pic x(127).

*----------------------------------------------------------------*
* In this example we will create a new process by executing
*
* NOTEPAD.EXE and loading the text file CREATEP.TXT. These are
*
* passed together in the Command-line parameter #2 so the
*
* application-name parameter #1 must be NULL.
*
*
*
* If the process should be run in background and not displayed
*
* use the SW-HIDE flag instead of SW-NORMAL.
*
*
*
* You can control how the new process behaves in a number of
*
* ways. In this example we issue a call to WaitForSingleObject
*
* so that this program will wait until the process terminates
*
* before continuing. If you would like to kill a process
*
* directly instead you could use the call to TerminateProcess
*
* using the process ID returned by CreateProcess.
*

*----------------------------------------------------------------*
procedure division.
000-begin.

*** If we wish to compile to .int code then cob32api.dll must be
*** loaded before Windows API calls can be made.

$if INTCODE=1
call "cob32api" end-call
$end

***
display PROGRAM-NAME ": Starting."

move length of startup-info to cb of startup-info
move SW-NORMAL to wshowwindow of startup-info
move z"notepad.exe createp.txt"
to executable-and-command-line

call staticWINAPI CreateProcess
using by value 0 size 4 *> application name is NULL.
by reference executable-and-command-line
by value 0 size 4 *> ret handle not inherited.
by value 0 size 4 *> ret handle not inherited.
by value 0 size 4 *> open handles not
inherited.
by value CREATE-DEFAULT-ERROR-MODE
by value 0 size 4 *> use parents environment.
by value 0 size 4 *> use current directory.
by reference startup-info
by reference process-info
returning ws-okay
end-call

*** Remove the comments following if you wish to kill the
*** process directly.

* if ws-okay = isTRUE *> Process created OK
* call staticWINAPI GetExitCodeProcess
* using by value hProcess of process-info
* by reference ws-app-return-code
* returning ws-okay
* end-call
* end-if

* if ws-app-return-code = STILL-ACTIVE
* call staticWINAPI TerminateProcess
* using by value hProcess of process-info
* by reference ws-app-return-code
* returning ws-okay
* end-call
* end-if

*** End of the Terminate Process API

*** We wait for the end of the process

if ws-okay = isTRUE
display PROGRAM-NAME ": Okay... Sleeping"
call staticWINAPI WaitForSingleObject
using by value hProcess of process-info
by value INFINITE *> No timeout
returning ws-okay
end-call

if ws-okay = WAIT-FAILED
display PROGRAM-NAME
": Failed to wait until process dies."
else
display PROGRAM-NAME ": Wait Complete."
call staticWINAPI GetExitCodeProcess
using by value hProcess of process-info
by reference ws-app-return-code
returning ws-okay
end-call

if ws-okay = isTRUE
display PROGRAM-NAME
": Return-Code = " ws-app-return-code
else
display PROGRAM-NAME
": Sorry no Return-code available."
end-if
end-if
else
display PROGRAM-NAME ": Failed to Create a New Process."
end-if.
stop run.

William M. Klein

2005-04-11, 3:55 pm

If MYhandle never equals 5, then this will loop forever. If it DOES equal 5,
then you should exit.

I should add that Micro Focus has an odd (IMHO) extension allowing the
End-Perform to be omitted from an inline PERFORM in *some* cases. I would avoid
that like the "plague".

--
Bill Klein
wmklein <at> ix.netcom.com
"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1113200605.456348.54080@l41g2000cwc.googlegroups.com...
> Bill,
>
> speaking of scope-terminators and end-performs, I was having problems
> with this
> particular cobol code in my windows procedure --- I could use your help
> on this one,
> does this coding style looks correct to you:
>
> move zeros to Myhandle
> perform until EXIT
> if Myhandle = 5
> exit perform
> end-if
> add 1 to Myhandle
> add some numbers or some cobol code here
> more cobol code
> end-perform.
>
> my program was hanging because of this perform statement --- the
> program went into an
> infinite loop, and never came back to planet earth again. Did I code
> this perform statement
> correctly??
>
> Kellie.
>

James J. Gavan

2005-04-11, 3:55 pm

Kellie Fitton wrote:
> Jimmy,
>
> to customize the skin of a dialogBox is simply to change its apprears
> dramatically, it is
> more than just slapping a bitMap image on its surface to hide the grey
> color. You would
> add more rounded and 3D buttons into the title bar to replace the
> default system menu,
> the corners of the dialogBox per se would be rounded as well to give it
> the illusion of
> being Floating on the screen. Also, each button would have a titleBar
> with its own
> property buttons for further menu selections and colour choices. The
> titleBar can also
> have toolBar buttons for more menu selections as well. Its very very
> blase, you know.
>
> Kellie.
>
OK, so you want to get fancy-schmantzy. You're already part way there
with your Technicolor Dialog :-). You can do some neat things, but only
use gimmicks or colours to highlight - not overpower the user.

I don't think you are going to lay your hands on code to do some of what
you want unless your find it at the MS site relating to APIs. All that
3D'ing and rounded corners is covered by draw/paint - and as Richard has
said in the past, reference APIs, 'don't get into the grubby details'.
Granted the time is fractional, but if you provide more than the basic
outline of a dialog, there's a pause between starting and first
displaying your dialog - recall sometime back you wanted some 'Prompt
message' while the dialog was being created.

Jimmy

William M. Klein

2005-04-11, 3:55 pm

Call "XYZ" *.with no exception
is the same as
Call "XYZ"
End-Call

It is NOT the same as

Call "XYZ"
End-Call
. *> with full-stop / period

In other words, the "end-call" is superfluous but does NOT end the sentence,
only the statement.

--
Bill Klein
wmklein <at> ix.netcom.com
"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1113231188.320554.219940@f14g2000cwb.googlegroups.com...
> Hi Richard,
>
> my understanding of an "end-call" clause is that it
> is simply equivalent to a full stop which is a dot.
> For example,
>
> call "MyProgram".
>
> is the same as
>
> call "MyProgram"
> end-call.
>
> I downloaded a sample program from Micro
> Focus's website that is called "CreateP", they
> are coding the "end-call" as well.
> here is the sample program from Micro Focus's
> webSite:
>
> $set ans85 mf defaultbyte"00" case constant INTCODE(0)
>
> *----------------------------------------------------------------*
> * CREATEP
> *
> *
> *
> * This example demonstrates the use of the Win32 API function
> *
> * call CreateProcess in order to execute a non-COBOL program
> *
> * from within a COBOL program. In this example, the Windows
> *
> * Text Editor NOTEPAD.EXE will be executed. The program will
> *
> * then wait until NOTEPAD has been exited at which point it
> *
> * will also exit.
> *
> *
> *
> * CreateProcess allows you to control how a program is started
> *
> * along with the parameters, the environment and the working
> *
> * directory that the new program should use.
> *
> *
> *
> * Parameters passed are as follows:
> *
> * 1. Application-name:
> *
> * Pointer to a null-terminated string that specifies the
> *
> * module to execute. The string can specify the full path
> *
> * and filename of the module to execute. The string can
> *
> * specify a partial name. In that case, the function uses
> *
> * the current drive and current directory to complete the
> *
> * specification. The Application-name parameter can be
> NULL.*
> * In that case, the module name must be the first white
> *
> * space-delimited token in the Command-line parameter.
> *
> *
> *
> * 2. Command-line:
> * Pointer to a null-terminated string that specifies the
> *
> * command line to execute. The Command-line parameter can
> *
> * be NULL. In that case, the function uses the string
> *
> * pointed to by Application-name as the command line.
> *
> * If both Application-name and Command-line are non-NULL,
> *
> * Application-name specifies the module to execute, and
> *
> * Command-line specifies the command line. If Application-
> *
> * name is NULL, the first white space-delimited token of
> the*
> * command line specifies the module name. If the process to
> *
> * be created is an MS-DOS - based or Windows-based applica-
> *
> * tion, Command-line should be a full command line in which
> *
> * the first element is the application name. Because this
> *
> * also works well for Win32-based applications, it is the
> *
> * most robust way to set Command-line.
> *
> *
> *
> * 3. Process-attributes:
> *
> * This points to a structure which determines whether the
> *
> * returned handle can be inherited by child processes. If
> *
> * Process-attributes is NULL, the handle cannot be
> *
> * inherited.
> *
> *
> *
> * 4. Thread-attributes:
> *
> * This points to a structure which determines whether the
> *
> * returned handle can be inherited by child processes. If
> *
> * Process-attributes is NULL, the handle cannot be
> *
> * inherited.
> *
> *
> *
> * 5. Inheritance-flag:
> *
> * Indicates whether the new process inherits handles from
> *
> * the calling process. If TRUE, each inheritable open
> handle*
> * in the calling process is inherited by the new process.
> *
> * Inherited handles have the same value and access privil-
> *
> * eges as the original handles.
> *
> *
> *
> * 6. Creation-flags:
> *
> * Specifies additional flags that control the priority
> *
> * class and the creation of the process. For a full
> descrip-*
> * tion of these flags see the Windows SDK Help file and
> *
> * search under CreateProcess. The constants for these
> values*
> * can be found in winbase.cpy.
> *
> *
> *
> * 7. Environment-block:
> *
> * Points to an environment block for the new process. If
> *
> * this parameter is NULL, the new process uses the environ-
> *
> * ment of the calling process. An environment block
> consists*
> * of a null-terminated block of null-terminated strings.
> *
> * Each string is in the form: name=value. Because the equal
> *
> * sign is used as a separator, it must not be used in the
> *
> * name of an environment variable.
> *
> *
> *
> * 8. Current-directory:
> *
> * Points to a null-terminated string that specifies the
> *
> * current drive and directory for the child process. The
> *
> * string must be a full path and filename that includes a
> *
> * drive letter. If this parameter is NULL, the new process
> *
> * is created with the same current drive and directory as
> *
> * the calling process.
> *
> *
> *
> * 9. Startup-info:
> *
> * Points to a STARTUPINFO structure that specifies how the
> *
> * main window for the new process should appear. This
> struc-*
> * ture is defined in winbase.cpy.
> *
> *
> *
> * 10. Process-info:
> *
> * Points to a PROCESS_INFORMATION structure that receives
> *
> * identification information about the new process. This
> *
> * structure is defined in winbase.cpy.
> *
>
> *----------------------------------------------------------------*
> id division.
> program-id. createp.
> special-names.
> call-convention 74 is staticWINAPI.
> data division.
> working-storage section.
> copy "miniwin.cpy".
> copy "wintypes.cpy".
> copy "winuser.cpy".
> copy "winbase.cpy".
> 78 PROGRAM-NAME value
> "CREATEP".
> 01 startup-info STARTUPINFOA.
> 01 process-info PROCESS-INFORMATION.
> 01 ws-okay BOOL.
> 01 ws-app-return-code DWORD.
> 01 executable-and-command-line pic x(127).
>
> *----------------------------------------------------------------*
> * In this example we will create a new process by executing
> *
> * NOTEPAD.EXE and loading the text file CREATEP.TXT. These are
> *
> * passed together in the Command-line parameter #2 so the
> *
> * application-name parameter #1 must be NULL.
> *
> *
> *
> * If the process should be run in background and not displayed
> *
> * use the SW-HIDE flag instead of SW-NORMAL.
> *
> *
> *
> * You can control how the new process behaves in a number of
> *
> * ways. In this example we issue a call to WaitForSingleObject
> *
> * so that this program will wait until the process terminates
> *
> * before continuing. If you would like to kill a process
> *
> * directly instead you could use the call to TerminateProcess
> *
> * using the process ID returned by CreateProcess.
> *
>
> *----------------------------------------------------------------*
> procedure division.
> 000-begin.
>
> *** If we wish to compile to .int code then cob32api.dll must be
> *** loaded before Windows API calls can be made.
>
> $if INTCODE=1
> call "cob32api" end-call
> $end
>
> ***
> display PROGRAM-NAME ": Starting."
>
> move length of startup-info to cb of startup-info
> move SW-NORMAL to wshowwindow of startup-info
> move z"notepad.exe createp.txt"
> to executable-and-command-line
>
> call staticWINAPI CreateProcess
> using by value 0 size 4 *> application name is NULL.
> by reference executable-and-command-line
> by value 0 size 4 *> ret handle not inherited.
> by value 0 size 4 *> ret handle not inherited.
> by value 0 size 4 *> open handles not
> inherited.
> by value CREATE-DEFAULT-ERROR-MODE
> by value 0 size 4 *> use parents environment.
> by value 0 size 4 *> use current directory.
> by reference startup-info
> by reference process-info
> returning ws-okay
> end-call
>
> *** Remove the comments following if you wish to kill the
> *** process directly.
>
> * if ws-okay = isTRUE *> Process created OK
> * call staticWINAPI GetExitCodeProcess
> * using by value hProcess of process-info
> * by reference ws-app-return-code
> * returning ws-okay
> * end-call
> * end-if
>
> * if ws-app-return-code = STILL-ACTIVE
> * call staticWINAPI TerminateProcess
> * using by value hProcess of process-info
> * by reference ws-app-return-code
> * returning ws-okay
> * end-call
> * end-if
>
> *** End of the Terminate Process API
>
> *** We wait for the end of the process
>
> if ws-okay = isTRUE
> display PROGRAM-NAME ": Okay... Sleeping"
> call staticWINAPI WaitForSingleObject
> using by value hProcess of process-info
> by value INFINITE *> No timeout
> returning ws-okay
> end-call
>
> if ws-okay = WAIT-FAILED
> display PROGRAM-NAME
> ": Failed to wait until process dies."
> else
> display PROGRAM-NAME ": Wait Complete."
> call staticWINAPI GetExitCodeProcess
> using by value hProcess of process-info
> by reference ws-app-return-code
> returning ws-okay
> end-call
>
> if ws-okay = isTRUE
> display PROGRAM-NAME
> ": Return-Code = " ws-app-return-code
> else
> display PROGRAM-NAME
> ": Sorry no Return-code available."
> end-if
> end-if
> else
> display PROGRAM-NAME ": Failed to Create a New Process."
> end-if.
> stop run.
>

Richard

2005-04-11, 8:55 pm

> my understanding of an "end-call" clause is that it
> is simply equivalent to a full stop which is a dot.

In many cases, both an END-~ clause and a full-stop will terminate the
current scope, but they are not interchangable and not equivalent.

One could also argue that, in many cases, an END-~ clause and _nothing_
are equivalent, where there is no conditional clause and the END-~ is
not required.

There is a note in what seems to be the standard:

"""In some cases the delimited scope statement with which an explicit
scope delimiter is paired, is determined differently for different
COBOL language specificaations."""

This is certainly true of PERFORM.

However, we were trying to explain your errors that arose from removing
'CONTINUE'. The effect of:

when ID-PUSHBUTTON4
continue

when other
call WINAPI ...
end-evaluate

Is quite different from:

when ID-PUSHBUTTON4
* continue

when other
call WINAPI ...
end-evaluate

So in that specific case the CONTINUE should not be removed, or perhaps
it should be, depending on the effect required.

But the effect of:

when WM-CLOSE
call WinAPI "EndDialog" using
by value hDLGbox
by value lnk-wParam
returning Return-Code
end-call
continue

when other
continue

Is identical to:

when WM-CLOSE
call WinAPI "EndDialog" using
by value hDLGbox
by value lnk-wParam
returning Return-Code
end-call
* continue

when other
continue

> I get when there is NO continue clause in my windows procedure
section.

If there are _NO_ continue _statements_ (it is a statement not a
clause) then as written it probably won't work correctly, but shouldn't
give compile errors as far as I can see from what the code would be.
_Some_ continue statements are extraneous and can be removed without
causing logic errors or syntax errors, some cannot.

As an aside, I dislike your use of:

perform UnicodeText.
....
stop run.

UnicodeText Section.
if MultiByteString not = spaces
.......
end-if.
exit section.

entry "MyDLGBoxProc" WinAPI using
by value hDLGbox
by value lnk-iMessage
......

The ENTRY statement is not a label and thus does not terminate the
UnicodeText section, or indeed any paragraph either. You have put in
an 'exit section' which will take execution to a point at the end of
the current section, in this case the end of the program. The entry
point and all the call back code is entirely within the UnicodeText
section.

This means that a PERFORM of UnicodeText is recursive with a callback
to the entry point. At the very least this will confuse a code
analyser, but it may also present technical problems in the run-time.

I would suggest that a section header be written before the ENTRY
statement.

James J. Gavan

2005-04-11, 8:55 pm

Richard wrote:
> However, we were trying to explain your errors that arose from removing
> 'CONTINUE'. The effect of:
>
> when ID-PUSHBUTTON4
> continue
>
> when other
> call WINAPI ...
> end-evaluate
>
> Is quite different from:
>
> when ID-PUSHBUTTON4
> * continue
>
> when other
> call WINAPI ...
> end-evaluate
>
> So in that specific case the CONTINUE should not be removed, or perhaps
> it should be, depending on the effect required.

Richard,

Your observation is correct on the basis of the info Kellie provided.
You just click on the pushbuttons and nothing happens.

Kellie,

Agreed it is only a skeleton but just to make the demo informative, for
each pushbutton you click on there should be a messasgebox saying "You
clicked on Pushbutton X". I ran it and clicked - got nothing - then had
to go back to your code to see that nothing was meant to happen.

As an alternative - take your four pushbuttons and label them "&Clear"
to empty your text fields, starting over again, "&Help" to bring up some
generic help-file and "E&xit" to quit the app as well as the "X"
top-right. Your fourth button - ??? = display "You hit the fourth button".

Jimmy

Kellie Fitton

2005-04-11, 8:55 pm

Jimmy,

inserting a messageBox for clicking any of the
pushButtons will serve no purpose whatsoever, I
intentionally kept it blank because this is where
you come in and inject your own cobol code,
based specifically on the function of that button.
First, you need to label your buttons with text that
describes their functions when they get clicked,
then, the cobol code at that location will perform
its function, once the button has been clicked.

when ID-PUSHBUTTON1
cobol function code for button1

when ID-PUSHBUTTON2
cobol function code for button2

when ID-PUSHBUTTON3
cobol function code for button3

when ID-PUSHBUTTON4
cobol function code for button4

I added four buttons because a dialogBox will
need four buttons for a professional data entry
operation. Case in point:

button1: Save
button2: Change
button3: Delete
button4: Browse

or

button1: Save
button2: Change
button3: Delete
button4: Clear

or

button1: Save
button2: Change
button3: Delete
button4: Cancel

or

button1: Save
button2: Change
button3: Delete
button4: Archive

or

button1: Save
button2: Change
button3: Delete
button4: Restore

just remember, COBOL is Cool.

Regards, Kellie.

LX-i

2005-04-12, 3:55 am

Richard wrote:
>
> A scope delimiter should only be necessary if the conditional clause is
> used in a statement. In the case of a CALL this is the ON EXCEPTION or
> ON OVERFLOW.
>
> CALL xxxx USING ...
>
> is an imperitive statement and does not need an END-CALL, in fact it is
> probably an error to have one.

It isn't, at least on the compiler I routinely use. I generally code
Calls like so...

call "some-entry-point"
using var1, var2, really-long-var-name-3,
var4
end-call

It brings the indenting back to the same level, and helps (me) read my
code when I go back to it the next time.

> For example:
>
> CALL "A" USING something
> ON EXCEPTION
> CALL "B" USING someerrorcode
> END-CALL
> DISPLAY "There was an error in calling A"
> .
>
> Will the DISPLAY occur:
>
> a) when CALL "A" fails
> b) when CALL "B" fails
> c) everytime the CALL "A" is executed

Ooo! A quiz! I love those!

I would say "c", unless "B" has a stop run in it... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

LX-i

2005-04-12, 3:55 am

LX-i wrote:

Okay, now I'm talking to myself...

> It isn't, at least on the compiler I routinely use. I generally code
> Calls like so...
>
> call "some-entry-point"
> using var1, var2, really-long-var-name-3,
> var4
> end-call

No I don't... :) I don't put in commas, but I do separate the variable
names by 2 spaces.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

James J. Gavan

2005-04-12, 3:55 pm

Kellie Fitton wrote:
> Jimmy,
>
> inserting a messageBox for clicking any of the
> pushButtons will serve no purpose whatsoever, I
> intentionally kept it blank because this is where
> you come in and inject your own cobol code,
> based specifically on the function of that button.
> First, you need to label your buttons with text that
> describes their functions when they get clicked,
> then, the cobol code at that location will perform
> its function, once the button has been clicked.
>
> when ID-PUSHBUTTON1
> cobol function code for button1
>
> when ID-PUSHBUTTON2
> cobol function code for button2
>
> when ID-PUSHBUTTON3
> cobol function code for button3
>
> when ID-PUSHBUTTON4
> cobol function code for button4
>
> I added four buttons because a dialogBox will
> need four buttons for a professional data entry
> operation. Case in point:

<snip>

OK, I know where you are going. But for starters that last statement is
wrong. A Dialog might require only TWO or perhaps FIVE buttons etc.
Depends upon what you are doing.

In effect you are suggesting you are creating a template on which you
can build. Sorry, but you have a long way to go. I might have it wrong,
but it seems to me that you are saying here's an outline, but by using a
'pick and shovel' approach, you copy the source for DialogA to become
DialogB, amending the second to include what you need. (I don't know
what is in your DLL because you only sent me the Release version).

Now it is achievable, but not, I would suggest using the approach you
have. We could dance around this one for ages, throwing in suggestions,
and still get nowhere. So let's get to some hard code. I'm just doing a
brief set of notes covering the Cheese Treeview - all OO of course. I'll
send to you. Promise you will compile and run ?

Ignore the OO concept, thinking in terms of your APIs rather than my use
of GUIs - but look at how the whole thing is "chopped up" into
segments/classes/separate routines - call 'em what you want. If you
really are after a template approach using APIs then focus on how I have
done it and use it as an example against which you can parallel.

Give me a couple of days before I send to you.

Jimmy

Kellie Fitton

2005-04-12, 8:55 pm

Jimmy,

here is what my previous statement said:

"I added four buttons because a dialogBox will
need four buttons for a professional Data Entry
Operation.".

Now, here is what I've learned in my programming
classes:
when you provide a dialogBox for data entry
operation, you need to take into account the
following functions:

1). Insert or append new records into a masterFile
2). Change or update records in the masterFile
3). Delete or archive records from the masterFile
4). Browse or print records from the masterFile

Therefore, you will need a Minimum of four buttons
on a dialogBox to accommodate and anticipate
the needs of the end-user ---- just like I said.

when you create the dialogBox from the memory
template, appending the needed controls to it is
Very Easy, its just like using the screen section
in cobol. Case in point:

SCREEN SECTION.
01 MyScreen.
02 BLANK SCREEN BACKGROUND-COLOR 1
FOREGROUND-COLOR 15.
02 LINE line-num COLUMN column-num
VALUE "Hello Cobol"
02 LINE line-num COLUMN column-num
VALUE "Hello Windows"

once you anchor the first control on the
dialogBox, then its just a simple formula of
incrementing the line-number and the column
number, in order to adjust or set the stride of
progress horizontally or vertically. Additionally,
you can use the win32 API's
"MapDialogRect", "AdjustWindowRect"
and "SetWindowPos" to relocate and repaint all
your controls on the main dialogBox.

I sent you a .DLL file that have an Icon image and
a bitMap image so you can see what the
dialogBox looksLike, when you run the executable
program that I have included in my project.

Regards, Kellie.

Richard

2005-04-12, 8:55 pm

JJG> OK, I know where you are going. But for starters that last
statement
JJG> is wrong. A Dialog might require only TWO or perhaps FIVE buttons
JJG> etc. Depends upon what you are doing.

> Now, here is what I've learned in my programming
> classes:
> ...

> Therefore, you will need a Minimum of four buttons
> on a dialogBox to accommodate and anticipate
> the needs of the end-user ---- just like I said.

I suspect that James' half century ;-) of experience with accommodating
end-user needs may have made him somewhat more reliable than that of a
teacher trying to simplify things for students.

dialog boxes may need just one button, or may need a dozen, I have done
both and most between.

Kellie Fitton

2005-04-12, 8:55 pm

Hi Richard,

how can I create a dialogBox with only one button,
when am trying to provide the end-user with the
needed capabilities to perform the following
functions: Insert, Change, Delete, Browse and
Print. ??

what I said to Jimmy was very clear and my point
was about data entry operation ---- what you said
however, is just a general statement that does not pertain to the point
nor to my previous comment to Jimmy.

Regards, Kellie.

Richard

2005-04-12, 8:55 pm

> how can I create a dialogBox with only one button,
> when am trying to provide the end-user with the
> needed capabilities to perform the following
> functions: Insert, Change, Delete, Browse and
> Print. ??

> my point was about data entry operation

Some Data Entry operations do not allow the end-user to Delete or
Change, for example to cater for strict auditing procedures. If an
error is made then the end-user must enter a corresponding reversal
entry. As the user code is recorded against each of the entries then
these can be used to track error rates. One problem with deletes is
that there is no record to hold the user code of the one that deleted
it.

There are more requirements out there than you may imagine.

James J. Gavan

2005-04-13, 3:55 am

Kellie Fitton wrote:
> Hi Richard,
>
> how can I create a dialogBox with only one button,
> when am trying to provide the end-user with the
> needed capabilities to perform the following
> functions: Insert, Change, Delete, Browse and
> Print. ??
>
> what I said to Jimmy was very clear and my point
> was about data entry operation ---- what you said
> however, is just a general statement that does not pertain to the point
> nor to my previous comment to Jimmy.
>
> Regards, Kellie.
>
As a general guide what your teacher taught you is correct. But bear in
mind he/she is trying to convey the basics. But at all costs work
against the idea of being dogmatic, that is, 'What teach said is
gospel'. Even he would probably be aghast if he realized that was the
message he was sending. So your Prof gives you a broad outline - adapt
it to suit the current problem.

Richard has already commented about NOT deleting etc., and you used the
word 'Masterfile' in an earlier message. Got to watch that one - it is a
general term from some decades back which really embraces two
categories, (and I have just 'invented' the two names) :-

Descriptive MasterFiles - like Customers, Vendors/Suppliers, Chart of
Accounts, Product Codes etc. These are the ones on which you perform
adds, changes and deletes - although with the latter you should signal :-

(a) "Sure you want to delete this record - You won't get a description
for printing. Yes/No ?" OR,

(b) "You can't delete this record. Customer # xxxxxx has an outstanding
balance".

Design-wise Descriptive Masterfiles generally, do not contain current
transaction info.

Data Masterfiles - GeneralLedger, Accounts Receivable, Payable or
Inventory file. You don't go messing around with these through a
'General Edit'. As Richard pointed out for the G/L you only make
debit/credit transaction changes which MUST balance and produce an audit
trail. You update the G/L now or at some later stage and as part of the
audit write your changes to a Journal Transaction file.

If you take an Inventory File, mostly it is 'updated' by receiving new
shipments 'IN', selecting ordered items which are subsequently shipped
and then invoiced. (Or internally within retail, items may be 'stock
transferred' to branches).

> functions: Insert, Change, Delete, Browse and
> Print. ??

Back in the 80s - and you aren't going to believe this - folks used to
produce programs for Editing a file - and they had AddCustomer.cbl,
ChangeCustomer.cbl, DeleteCustomer.cbl and PrintCustomer.cbl. Four
completely separate programs each REPEATING a lot of the junk which was
relevant to them all !

You have 'Insert' above. I'm trying to think hard, but I don't think I
have an Add/Insert anywhere. Display Dialog with empty record format and
Listbox to right containing a display of existing records. So user
either selects a record from the Listbox, (which means it is displayed
for the user to start Changing or hits Delete button), or keys-in
against the empty Account # in the record format, (which means the
intent is to Add a new record). See how variable it can be, depending
upon design, not mine, not his, nor hers, but YOUR DESIGN.

Jimmy

Kellie Fitton

2005-04-13, 3:55 am

Richard,

you are making a general assumption based on the labels that is
displayed on
a dialogBox's buttons, without knowing the specific designs of a
particular software or
system. Clicking the delete button does not means that the record will
be Obliterated
from planet earth. Likewise, clicking the change or modify button does
not means that
the record will have a gender change operation, and will become
completely
irReversible. :---)

I could conjureUp a software system with a delete button, that is
programatically
designed to move records from one masterFile, and dump them into an
archived file,
or perhaps send some records into a file, that is designed to function
as
a recycleBin for a temporary storage. Also, some software systems would
insert an
asterisk into a record, just to mark them as deleted temporarily, which
will allow for
a status reversal at a later date, if the end-user wishes to do so.

Like the delete button, a change button could send a request message to
activate
a subSystem program, so the end-user would be able to upDate a
customer's mailing
address and a zipCode number, in a temporary file, which can be
processed later on,
and will allow for an audit-trails at a later date, or perhaps submit
an entry in a correction
file to reverse an error that was made by the end-user, that must be
corrected
immediately before a monthly batch process starts to run, and produces
some reports with some erroneous result.

There are more requirements out there than you may imagine.

Regards, Kellie.

Richard

2005-04-13, 3:55 am

> you are making a general assumption based on the labels that is
> displayed on a dialogBox's buttons,

No, I am not making any 'assumptions' at all. I am relating _actual_
end-user needs that happen to differ from the model that you prescribe,
I neither know nor care what your 'Delete' button does but I do know
some systems where it would be inappropriate to have one.

> Clicking the delete button does not means that the record will
> be Obliterated

I would suggest that it is likely that an end-user would think that a
'Delete' button would make the record removed and unavailable.

> I could conjureUp a software system

Well, you may do so, however, I was relating actual experience of real
life systems where a 'Delete' button was inappropriate, even if what it
did was something else. All the software that you may dream up does
not invalidate my description of some real-life _actual_ end-user
needs.

You may also want to note that there may well be some systems that
require add/amend/delete/list, I was not arguing that design is wrong,
only that it is not universal (ie I said _Some_ ..).
[color=darkred]

Like James I wouldn't bother with 'Insert' or 'Amend' buttons. That
can make a clumsy user interface. On many of my input dialogs there is
a primary key input field, the user keys in the code (the other fields
are protected) and tabs out. If the code exists it displays the details
and allows editing of the fields, if not it clears the input fields and
allows input. There is a 'Save' button which updates or inserts the
record as appropriate.

'List' buttons may exist but I tend to use function keys so that from
the input field the user may input a partial key or search and press,
say, F7 (or the 'list' button). Buttons require switching between
keyboard and mouse and this slows down the user. Both should be
available.

William M. Klein

2005-04-13, 8:55 am

Richard

2005-04-13, 8:55 pm

Richard

2005-04-13, 8:55 pm

Joe Zitzelberger

2005-04-14, 3:55 am

In article <1113231188.320554.219940@f14g2000cwb.googlegroups.com>,
"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote:

> Hi Richard,
>
> my understanding of an "end-call" clause is that it
> is simply equivalent to a full stop which is a dot.
> For example,
>
> call "MyProgram".
>
> is the same as
>
> call "MyProgram"
> end-call.

Call has some other options -- for example, exception handling:

Call "MyProgram" using a b c
returning d
on exception
add 1 to number-of-errors
perform complain-to-user
perform log-error-to-file
...more stmts...
End-Call

(I'm not sure if exception or overflow is the normal standard Cobol
approach -- either works on IBM compilers.)

Richard

2005-04-14, 3:55 am

> (I'm not sure if exception or overflow is the normal standard Cobol
> approach -- either works on IBM compilers.)

I think that both are standard ANS'85. ON OVERFLOW was ANS'74 (and
possibly before). ON OVERFLOW implies that the program cannot be
loaded due to not being sufficient memory, while ON EXCEPTION implies a
wider range of error conditions.

I suspect that in most implementations they are synonomous.

Kellie Fitton

2005-04-15, 8:55 am

Kellie Fitton

2005-04-15, 8:55 am

Kellie Fitton

2005-04-15, 8:55 am

Kellie Fitton

2005-04-15, 8:55 am

Kellie Fitton

2005-04-15, 8:55 am

Richard

2005-04-15, 8:55 am

as to why you are using a 'handle'.

It may be that 'more cobol code' is changing the variable Myhandle by
using it as a return from a call so that it never gets to be = 5.

James J. Gavan

2005-04-15, 3:55 pm

Kellie Fitton

2005-04-17, 3:55 am