home *** CD-ROM | disk | FTP | other *** search
/ Piper's Pit BBS/FTP: ibm 0020 - 0029 / ibm0020-0029 / ibm0028.tar / ibm0028 / PV31-4.ZIP / PGREADME.DOC < prev    next >
Encoding:
Text File  |  1991-02-01  |  5.0 KB  |  98 lines
  1. All users of ProtoGen 1.0 should be sure to read #1 below to be sure they
  2. understand how code regeneration will be performed for their viewprocs.
  3.  
  4. Tips Tricks and Traps for non-Windows programmers using ProtoGen
  5.  
  6.  
  7. Contained here is a list of do's and don'ts for those users of ProtoGen
  8. who may not be completely familiar with the Windows programming
  9. environment.  It should also be used as a guide to experienced Windows 
  10. programmers to avoid problems that may arise in the compiled executable.
  11.  
  12. If you encounter problems with the code generated by ProtoGen or with
  13. the execution of the compiled version, you should check this list to see
  14. if there are such circumstances within your code.  While ProtoGen can
  15. generate a fairly complex application, given the proper input, it is
  16. neither a compiler nor an enforcer of application design rules and
  17. consequently it is capable of producing generated source code that
  18. may not fully meet expectations.  If you encounter problems that you
  19. cannot overcome using these guidelines, you can freely call ProtoView
  20. Development Co. for technical support.
  21.  
  22.  
  23. Here then are some basic rules to follow in your use of ProtoGen.
  24.  
  25. 1. Users of ProtoGen version 1.0 may experience a slight problem with 
  26. code regeneration within viewprocs for dialog modules.  This is because 
  27. ProtoGen now generates a regeneration bracket outside and separate from 
  28. the viewproc code  for subdialogs.  The first time code regeneration is 
  29. performed on a module generated by ProtoGen 1.0 there will be a block of 
  30. code between these regeneration brackets that does not compile 
  31. correctly.  You will need to go in to the module itself and remove any 
  32. code you do not want from the bracket and keep any code you do want.
  33.  
  34. The problem can be avoided completly by either turning off code 
  35. regeneration, or by answering NO to confirm module overwrite messages 
  36. for those screens that do not need code regeneration.
  37.  
  38. 2.  ProtoGen does not perform variable definition checking for field
  39. names defined under ViewPaint.  If the same field name is used in two or
  40. more screens within the application, then an error may be generated when
  41. the application is compiled.  The same is true for FieldProc names.
  42. ProtoGen attempts to avoid this problem by prefixing the view name to 
  43. the variable.  
  44.  
  45. Also, do not use a variable name that is identical to either a screen
  46. name, or a FieldProc name, or a ViewProc name.
  47.  
  48. In short, be sure that all identifiers are uniquely named in order to
  49. ensure correct code generation and compilation.
  50.  
  51. 3.  Each screen that is part of a ProtoGen application must be uniquely
  52. named.  Although ProtoGen may be able to distinguish between
  53. indentically named screens if they are contained in different files,
  54. Windows will always obtain only the first one encountered in the
  55. application resources when the program is executed.  Therefore, do not 
  56. use the same view more than once in an application.
  57.  
  58. 4.  Do not attach screens created with the SDK Dialog Editor as
  59. ProtoView screens to an application, and do not attach screens created
  60. with ViewPaint as Windows dialogs to an application.  This choice is
  61. made on the Dialog Specification Screen in ProtoGen.  ProtoGen will
  62. default to the correct choice according to the extension on the dialog
  63. resource file. Windows dialogs have an extension of .dlg, while
  64. ProtoView dialogs have an extension of .pvt.  Do not override this
  65. unless you can deal with the potential consequences.
  66.  
  67. In particular, to not generate a dialog screen containing buttons with 
  68. the ProtoView styles of BS_OKAY and BS_CANCEL as Windows dialogs.  These
  69. styles are incompatible with the Windows dialog manager and will lead to
  70. serious problems in the executable.
  71.  
  72. 5.  If you use the Dialog Editor to create a .dlg resource, be sure to
  73. give the dialog a style of WS_VISIBLE.  This will allow the screen to be
  74. made visible when displayed in the program executable.  Otherwise a
  75. screen may be created but yet it will not be visible, thus creating the
  76. appearance of a serious problem.
  77.  
  78. 6.  In order for a dialog to be dismissed when an OK or Cancel button is
  79. clicked during program execution, if must contain buttons with specific
  80. properties.  The specific properties needed depends upon whether the
  81. screen is a Windows Dialog or a ProtoView screen.
  82.  
  83. If the screen is a Windows dialog, then it must contain two pushbuttons.
  84. One must have an ID of IDOK and the other must have an ID of IDCANCEL.
  85. These IDs are given in the Dialog Editor as part of the header file
  86. associated with the .dlg file.  For more information on specifying these
  87. IDs consult your SDK manuals on using the Dialog Editor.
  88.  
  89. If the screen is a ProtoView dialog or view, then it must contain two
  90. pushbuttons as well.  One button must have a style of BS_OKAY and the
  91. other must have a style of BS_CANCEL.  You can either drop these buttons
  92. in under ViewPaint using the Option: Add OK/Cancel Buttons, or you can
  93. add the style BS_OKAY and BS_CANCEL to existing buttons and clicking
  94. on Set.
  95.  
  96.  
  97.  
  98.