From the Editor
Written by Larry Salomon, Jr.
|
|
From the EditorWritten by Larry Salomon, Jr. |
|
Yes, the mailing distribution was goofed up. Many of you received parts 1 and 4 only. This is because the mailer runs Sendmail in the background but forgets to wait for it to complete before deleting the files it is supposed to be mailing. Oops. My apologies for the inconvenience. The fix to the problem has been volunteered by Gess Shankar, who runs the OS/2 Multimedia Mailing List. He offered to run the mailing distribution using his tried-and-true mailing list machine. This will allow for much more robust subscription processing as well as the ability to request back issues; those of you who are currently subscribed via the "old way" have already been moved to the new machine, so there is no need to resubscribe. To receive more information (for new readers), send an empty mail message to EDM2@knex.via.mind.org and you will receive the information file that tell you how to subscribe, etc. I still have not heard from Gavin Baker so I will assume him to be "missing in action"; because of this I will be writing the "Introduction to Presentation Manager Programming" column and will start over from the beginning. Speaking of people missing in action, I received a note from Steve (Luzynski). He is doing well and now has a full-time job as a computer retail salesperson which leaves him with "no free time." I guess that answers the question I had about really being the editor or just being a stop-gap until he came back. By now, many if not all of you have heard of WordPerfect's announcement to halt development on WordPerfect version 6.0 for OS/2. Who knows what this portends? I certainly do not, but I do know that I am glad I am not in Orem, Utah right now...You are probably thinking, "what the hell does this have to do with OS/2 development." Consider that a company of that size makes a decision like this for one of three reasons: political alliances could indicate a conflict of interest, marketing demand could indicate it is not worth the investment, or development strategies in the environment could make the product obsolete in a short time. My hunch is that they know something we don't about IBM's direction but we had better find out! There is both a correction and a clarification that are noteworthy in the Scratch Patch column. Also, we need your submissions for the Snippet(s) of the Month portion of that column! Not only is group participation better, but this old dog hasn't learned all of the possible tricks in OS/2 programming. I am always looking to grow, too! (Editors note: the Scratch Patch column has been split. The Q&A section is in "Questions and Answers", the snippets of the month is in the separate section "Code Snippets & Tips" the rest follows below.) While talking to Dick Conklin a few days ago, he asked me to mention that you might qualify for a free subscription to OS/2 Developer, another OS/2 magazine aimed at developers. Call 1-800-WANT-OS2 and ask them for the form to fill out. If you are a member of the Developers Assistance Program (DAP), be sure to indicate this on the form to guarantee your acceptance. Some other tweaks on the magazine were made, notably, the icon file has been renamed to EDMI.ICO and the installation program has been changed accordingly. This will allow you to remove all of the previous icon files and only keep the latest on your disk. Also, an ASCII file containing the table of contents will be distributed with each issue as CONTENTS.NDX to allow you to see the titles of the articles for that month. The contents of issues 1 through 6 can be found in the Reader's Choice Awards in this issue and can also be found in the .ZIP file as OLDNDXS.NDX Many thanks to the readers who suggested these changes. Finally, I knew this was going to happen and it did. I forgot to add two
articles to this month's index - OS/2 Installable File Systems - Part 3 and
Using OS/2 2.x bitmap files. Because of this, I am resending this; I would
hate for them to not be considered for the Reader's Choice Awards because
of my screw-up.
Since I meant to mention this last month but forgot, I have a correction for the "Help Manager and Online Documentation" article in the October issue. It is really not a correction, but instead a better way of doing message box help. The idea is to create a dummy HELPSUBTABLE and then for each message box help id, create a HELPITEM whose first and third identifiers are the message box help id, and the second identifier is of the dummy HELPSUBTABLE. The idea is that when the user requests help, the HELPSUBTABLE will not have the appropriate entry and so the Extended Help panel (the third parameter) will be displayed. The advantage of this is that of performance; hooks are performance eaters, so this is a nice reason to do this (according to Scott Kliger, the developer of the original Help Manager code). The disadvantage of this is that for larger applications with large numbers of different message boxes, the HELPTABLE can get rather unwieldy. Another clarification is about last month's "Threads in PM Applications" article, where the call to DosSleep() was made in the processing of the MYM_ENDTHREAD message. The use of this function within a PM application is strongly discouraged because it can lock the system up until the call returns, but if used with caution will cause no noticeable effect. This case is just that; the thread is already dying, so the loop with the DosSleep() body will execute a minimal number of times. Thanks go to Michael Hohner (fn0728@cd4680fs.rrze.uni-erlangen.de) for sending us both of these items. Also, in issue 5, I stated that, for user painted buttons, BDS_DEFAULT was incorrectly defined. Instead, it is correctly defined and I was misinterpreting the definition of default. Default in this sense does not mean "paint in the default manner", but instead means that the button is the default button and should be drawn with a darker border. This is a flag that can be specified in addition to the others (BDS_HILITED and BDS_DISABLED) which are mutually exclusive of each other. A value of 0 can still be received for fsState (in the USERBUTTON structure, so a new constant should be defined for this value (I named it BDS_NORMAL). Documentation Chop ShopA few of you may have noticed, but in the OS/2 2.1 Toolkit, IBM once again forgot to define the container record attribute CRA_SOURCE. It is wise to define it directly in the pmstddlg.h file with the value 0x00004000L. When we received our copy of the new C-Set++ compiler, I installed it and immediately proceeded to test for a successful installation by writing a C++ style "Hello world" program. After many unsuccessful attempts to get the program to link successfully, I was told that the compiler does not insert the default library object record for the C++ class libraries and that the user must do so explicitly. This is not stated in the documentation; the libraries are listed below:
It should be noted that statically linking these libraries ballooned the "Hello world" application to 131584 bytes! It is thus recommended that you use the dynamically linked run-time (DDE4MUII.LIB for the standard/user-interface class libraries and DDE4CCI.LIB for the container class libraries) and distribute the DLL's (which are royalty free, but require that you agree to the conditions listed on page 12 of the "C/C++ Tools License Information" pamphlet) with your application. In issue 2, I described how dropping on a printer does not send you a pointer to the DRAGINFO structure, but instead to a DRAGITEM structure corresponding to one of the items dropped on the printer sending the message. Well, it appears that, in OS/2 2.1, the system forgets to grant you access to the structure (if you think about it, however, this makes more sense than before, but they should still pass the PDRAGINFO structure instead). How do you access the data? Well, fortunately, the DrgAccessDraginfo() function is not picky about whether or not its argument is a PDRAGINFO or a PDRAGITEM, so insure that you call this function before trying to access the structure's contents, or you are sure to receive a protection violation. As a related topic, when you are initializing the PDRIVDATA field of the DEVOPENSTRUC structure, after allocating the memory, do not forget to set the cb field equal to the size of the buffer. Otherwise, calling DevPostDeviceModes() to initialize this buffer will cause a protection violation. Want AdsBelow are the hot topics as of this issue's writing. Feel free to write on any of these.
Reader's Choice AwardsIt is the end of our first calendar year in production and since we released our first issue in March of this year, we figured it made more sense to do this now instead of in February (otherwise, we will receive many questions asking why we didn't do this now). So, without further ado, 'tis time for... The First AnnualThe editors want to know what you think the top three articles written during the past year are. Please mail your responses to os2man@panix.com and indicate on what network you get EDM/2, if it is not the Internet (or the auto-mailer). For your convenience, the article titles have been included below. The "rules of the game" are...
The winners of the Reader's Choice Awards not only get recognition in the next issue of the magazine, but they will also get a goodie (or two) which will not be revealed until the next issue. An index of the past seven issues:
|