| Title: | DECWINDOWS 26-JAN-89 to 29-NOV-90 |
| Notice: | See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit |
| Moderator: | STAR::VATNE |
| Created: | Mon Oct 30 1989 |
| Last Modified: | Mon Dec 31 1990 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3726 |
| Total number of notes: | 19516 |
Hi, A small group of developers are sat in an office in the U.K., developing a DecWindows application for a customer who has said he will buy it when we've completed development. So far so good, now after analysing the application we have decided it will have three principle windows, - would like to say "main windows" but it would be missleading. These windows have been developed separately as stand alone DecWindow programs and seem to work OK. Now the question is, yes you've guessed it, how do we integrate them into one application. Initial ideas are:- 1. Since we have an application manager window in addition to the three mentioned above, we could call them as callbacks from a menu bar on this manager window. This would be the "Single VMS process" approach. 2. Second idea, not so well defined, is to have a separate VMS process for each principle window maybe all kicked off when the application fires up and displayed when requested to do so from the manager window somehow. This is the "Multiple VMS process" approach. A point to consider is that information will have to be passed between the programs driving the principle windows. At this stage it is not thought to be significant in size and will probably be passed around via a global section in memory. Link times and debugging is also a concern, i.e. we don't necessarily want to link the whole application every time we modify and test the software for just one principle window. If anybody out there has any experience of writing DecWindows applications, and I'm sure there must be, and feels they would like to comment, any advice would be much appreciated by us initially, our customer in the middle term, and the man who counts the proffits eventually. Pete Francis. U.K. Manufacturing ACT.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2137.1 | GOSOX::RYAN | DECwindows Mail | Thu Jan 25 1990 08:11 | 29 | |
>1. Since we have an application manager window in addition to the three > mentioned above, we could call them as callbacks from a menu bar on > this manager window. This would be the "Single VMS process" approach. Assuming the three separate programs are well-enough modularized, you should be able to do this easily enough. The callback would create a shell widget (XtAppCreateShell or some such) as the parent for each window (which, of course, should no longer call XtInitialize - this should only be done once in the process). >2. Second idea, not so well defined, is to have a separate VMS process for > each principle window maybe all kicked off when the application fires up > and displayed when requested to do so from the manager window somehow. > This is the "Multiple VMS process" approach. > A point to consider is that information will have to be passed >between the programs driving the principle windows. At this stage it is >not thought to be significant in size and will probably be passed around >via a global section in memory. This is also practical, but I would recommend against using global sections. Use the capabilities of DECwindows - global selection and/or client messages sent with XSendEvent. This will be a much more portable solution, enable you to have the processes run on different nodes, and if you use ICCCM conventions for passing information, enable them to communicate with other ICCCM-compliant applications. Mike | |||||
| 2137.2 | multi-threads and widgets... | RTL::OBRYAN | When in doubt, let the user decide. | Thu Jan 25 1990 15:21 | 16 |
re:.0 Have you considered using a single process with multiple threads? This would get around the problem of passing data between separate, autonomous processes. > These windows have been developed separately as stand alone DecWindow > programs and seem to work OK. > Now the question is, yes you've guessed it, how do we integrate > them into one application. If each of your "main window" applications is general purpose, you might consider "widgetizing" them. As widgets, the communication methodology between the "application" and the calling program is cleanly defined, and information availability as broad or restricted as the widget wishes to make it. | |||||
| 2137.3 | Thanks! | NRMACK::FRANCIS | I can "C" clearly now! | Fri Jan 26 1990 04:58 | 4 |
Thanks for your advice which is gratefully accepted. We have to
consider the pros and cons now I guess, and then choose.
Pete
| |||||