Dear Simon/Mark, Here is a proposed plan of attack for the development of the ActionFile dll. It takes into account Simon's message of 20/1/98 "Softoption DLL", although we will not need the INITIALISE/CLOSE functions described in that e-mail, (since SO does the intialisation and opening of PAYW rather than the other way round). The details of the Accept/Display functions in this e-mail might need altering slightly as well (depending on how exactly we implement test messages). How does it seem? Are there any mistakes (conceptual or otherwise)? ActionFile DLL -------------- This DLL will implement communications between ActionFile's COBOL application (PAYW.EXE) and SoftOption. It will be written in C/C++ and compliled using a 16 bit version of Microsoft Visual C++. This DLL will define the following classes: SODLLCom - SO's class for communicating with the SO software. This is the interface into the DLL which both PAYW and SO will use. We can use the declarations/definitions sent by Mark (except, see Stage 1b below...?). CobolTube - A subclass of SODLLCom which implements the passing of information between SO and PAYW. This will need writing more or less from sratch (but based on samples - File and DosObject - supplied by Mark) NB - The name of this class can be changed and is only for reference within this document. Anyone got strong feelings on this? Buffer - A class implementing a simple buffer (probably about 4K) with semaphore protection Important parts of these classes include: * The ability to convert screen images from PAYW into VT220 screens * The ability for PAYW to post windows messages to the SO window telling it that it has work to do * The ability to configure the SODLLCom instances by reading an ini file The following is a proposed plan for implementing the DLL and integrating it with SO and PAYW in an incremental fashion, highlighting which part of the communications process is being implemented/tested at each stage. Stage 1a - Dummy SO and Dummy PAYW ---------------------------------- In this stage, each of the applications will be simulated by a skeletal C/C++ program which loads the DLL and perform some trivial actions. Demonstrates : Simple communications between 2 applications via the DLL SODLLCom - No changes needed to example code sent by Mark (except to remove the code that reads the ini file) CobolTube - We need to implement * a constructor function * a destructor function * open * close * read (first implementation) * write (first implementation) Buffer - We can implement this (reletively simple) class Dummy SO - This program will 1) load the DLL 2) create a CobolTube instance 3) Call CobolTube::open to launch the Dummy PAYW application 4) Write some data into the DLL Dummy PAYW - When this has been created it will 1) read data from the DLL (pause to give dummy SO the chance to write it) 2) write the same data into the DLL Dummy SO will then read, and display, that data. (after pausing to let dummy PAYW write its data) Notes : The main application is the dummy SO in that it calls the other app. This is the opposite way round to that suggested by Simon in an earlier e-mail. Work Required : MJC to produce the 2 applications and initial DLL. MJC Time Required : 1-2 days Stage 1b - Add Conversion to VT220 strings ------------------------------------------ In this stage we will extend the DLL by converting data from the dummy PAYW into VT220 escape sequences. Mark suggested that we have a function that PAYW can call, with a prototype similar to: ComputeUpdates(unsigned start_point, unsigned max_extent, char *data, unsigned int foreGroundColour, unsigned int backGroundColour, unsigned int attributes;) This can be: 1) inside the (dummy) PAYW application (the code we have, however, is in C/C++) 2) inside the CobolTube class (how do we decide when 'write' should apply the the conversion or not - depending on whether PAYW or SO is writing data? Can we easily find this out?). I assume that PAYW would not be able to call this function directly, as it is not part of SODLLCom. 3) as an extension of the SODLLCom class, which the COBOL application can call directly. Is this possible? Does it have implications for SO dynamically linking our DLL? I am unsure which of these approaches we should use. Any thoughts? Most of the code for this function has been supplied by Mark. Work Required : MJC to insert conversion routine MJC Time Required : 0.5 days Stage 2a - Dummy SO and Real PAYW --------------------------------- In this stage, we will replace the Dummy PAYW with the real COBOL system. This will involve PAYW sending at least one string to the dummy SO app which will be converted to VT220 escape sequences and will be displayed by the dummy SO app. The dummy SO app will then send a dummy keyboard input back to PAYW. Demonstrates : Acutal COBOL to C/C++ communications via the DLL. This will involve implementing (initial versions of) the proposed Display and Accept functions in PAYW. These will call, respectively, the DLL's write and read functions during this stage. (After writing the input, PAYW will merely wait for a second or two until the dummy SO reads it and then writes its return strings. The dummy SO will just query the DLL in a cycle until it gets data from the DLL, and it will then send its dummy input string. PAYW will finish waiting and read the input from the DLL. This means that the communications between the 2 applications is miminal (only via read/write). Neither application will notify the other of its actions in this stage). Work Required : MJC & SS to integrate PAYW with the DLL. MJC Time Required : 1-2 days Stage 2b - More Intelligent communications ------------------------------------------ In this stage, the Dummy SO will be extended to receive, and react to, windows messages sent from the DLL. The DLL will filter each message on the dummy SO's message queue to see if the app needs to take an action (usually read). We will also improve PAYW handling of reading and writing. Demonstrates : 'Proper' comunications between PAYW and dummy SO. We will need to extend the Display and Accept functions in PAYW to handle this more flexible arrangement. It should be able to send arbitary screen updates to the dummy SO (which it should acknowledge) and receive input from the dummy SO. We will also need to implement CobolTube::idle, CobolTube::handler, and CobolTube::attach How will this work exactly? My thoughts are: 1) PAYW calls its display function. This calls a function in the DLL (ComputeUpdates) which posts a message to SO telling it to read its input data. SO should then read the data and act on it. 2) When PAYW needs to read data, it calls the read function. Does SO send any data it has then, or will it have already written it to the DLL? What if there is no data? Will we need to have the facility to post a windows message to SO at this point, and if so, where is the message generated (the options are the same for those in stage 1b, I feel, i.e. in PAYW - can it send windows messages? -, in the CobolTube object - if we can tell that is PAYW writing -, or by extending SODLLCom). This is based on the idea that PAYW has control of when it reads from or writes to the DLL, and that (if needed) it can 'tell' SO to do something (read data or provide keyboard input to PAYW). SO cannot 'tell' PAYW anything (including that it has sent information to the DLL) until PAYW decides to ask the DLL what SO has been up to. With this be sufficient for our needs? Work Required : MJC to extend dummy SO to accept windows input. SS to update Accept and Display functions MJC Time Required : 1 day for MJC work Stage 2c - Updated Accept and Display functions ----------------------------------------------- In this section we will update the accept and display functions in PAYW so that they are flexible enough for the real application. Work Required : SS to update functions MJC Time Required : 0.5 days?? Stage 3 - Real PAYW and SO -------------------------- In this stage the dummy SO is replaced by the actual SO application. We will need to standardise on the windows messages that we use for SO/DLL comms, adding the ability to read an ini file to initilise SODLLCom and check that the communications still work as they did in Stage 2. It might be sensible to have "canned responses" from SO at this point (i.e. predetermined input/ouput sequences) before moving on to a full implementation. Work Required : MJC, SS and MH to integrate real SO. MCJ Time Required : 1-2 days Stage 4 - Customise SO ---------------------- The rest of the work is to get SO actually doing the work it needs to do in displaying PAYW's output and sending keyboard input to PAYW. Time Summary ------------ The ammount of work required from MJC is: Stage 1a : 1-2 days Stage 1b : 0.5 days Stage 2a : 1-2 days Stage 2b : 1 day Stage 2c : 0.5 day Stage 3 : 1-2 days I have already spent almost a day (7hrs 50 minutes, in fact) pre-sales consultancy, which I propose to charge for upon confirmation of the project. Total 6 - 9 days. MJC will charge 300 pounds per day, although the invoice will be presented by Tim Joyce of HOOP. MJC will accept a copy of MSVC++ as part of this payment, although the details of this need to finalised. The figures above assume fairly trouble-free development of the software. It is always possible in these situations that an unforeseen problem will occur which will increase the time required to produce a final version of the software. ---------------------- How does this seem? Have I missed anything, not understood something or taken the wrong approach? Looking forward to your comments, Myles