Feedback Search Top Backward Forward

Questions and Answers

Written by Larry Salomon, Jr. et al.


To write to EDM/2, send your email to and use the Subject: line "Letters".

HTML Revisited

Ernest T Christley ( writes:

"I took interest in the fact that with issue 4 many of your readers are requesting EDM/2 in HTML format. You should seriously consider adopting Howard Gilbert's 'Sphydir'. It will generate HTML and IPF code simultaneously, and makes HTML production a no-brainer, drag-and-drop, WPS enabled walk in the park."

Scratch Patch Resurrected writes:

"If you still answer these in EDM/2, I have a question that shouldn't be too difficult...(why do I feel like I've missed something really obvious?)

I've noticed in several of the IBM apps (ex. VIEW.EXE) which use an MDI, the main window's system menu is the standard system menu. However the system menu on any child windows is different in that it uses CTRL key combinations instead of ALT key combinations. I've noticed this behavior in several MDI type Windows applications. Is there a simple way to do this for child windows, or would I have to 'manually' change each system menu entry at window creation time?"

Larry Salomon Jr. responds:

What needs to be done is to create your own accelerator table in your resource file, load it using WinLoadAccelTable, and then set it as the child frame using WinSetAccelTable. On the WinSetAccelTable call, make sure that the last parameter is not NULLHANDLE, or you'll replace the accelerator table for the entire application.

Sprites and the Magical Color Black

Jonathan Abbey ( writes:

"Hi Larry. I'm trying to make use of some of the ideas that you put together in the sprite library you presented in EDM/2. I'm trying to do this on a cross platform basis (we are developing class libraries for a game we're doing and we want the class interface to be portable across OS/2 PM, X, and Windows, if not Mac as well), and I'm wondering whether the techniques you presented would be able to work if the transparent color was not black.

That is, is there something magical about black? Is it guaranteed to map into all 0 bits on the display or something?

I guess if I can't figure out some way to be able to use an arbitrary transparency index, I could remap things, so that all black turns into 0,0,1 or some such, and the transparency index is converted to black.

I guess the only other ways of doing it would be by using GpiSetPel and/or by cutting chunks out of large sprites, convert them to icons, and blit them bit by bit to an off screen buffer, then swap it onto screen.

Yuck. I can't believe the GPI doesn't provide for 3 blit operands.

Anyway, thanks for any clarification you might be able to provide."

Larry Salomon Jr. responds:

The color black was chosen in conjunction with the ROP operation specified in creating the monochrome bitmask. Think of how the process works conceptually and then consider how you would create the mask. You might be able to try the mapping method that you hinted at, but I do not know if it would work. Converting the sprites to icons will not work because the algorithm presented in the series is identical in concept to that which the system uses, except that the application is responsible for creating the masks and not the system.

Custom Controls Needs a Custom Fix

Mark Mathews ( writes:

"The article 'Building Custom Controls' was great! We are porting DEU (for DOOM) to OS/2 and we have been stuck on how to make a status bar for about 1 month. Thank you!!!!!

In the EDITOR1 example one should use the height from MINMAX instead of the MENU. The reason is when changing the window size the height of the menu may change, where MINMAX will not change.

Did anyone try to compile the source code with C Set++ 2.1? I tried to compile EDITOR1.RC and I keep getting errors on MIS_BITMAP. I'm not sure yet. I'll investigate.

I'm sending you EDITOR2.ZIP. I modified EDITOR to only have a status bar and vertical and horizontal scrollbars ONLY. It works fine. My question is, what is the the square windows on the lower right side of the window where the horizontal and vertical scrollbars meet? For some reason that section has become transparent. Can you help me?

I also want to say excellent work on the article 'Making Executable Smaller.' Could the author expand on the subject of optimizing C code. Over the years there are little tricks you can use to make the code faster and smaller. For example, junk =3; if (temp==45) junk = 5; is faster and smaller than: junk = temp==45 ? 5 : 3

BTW, if EDM/2 goes public please don't write articles like the other programmers' magazines. Continue just what your doing. If you do that I will be first in line to buy an EDM/2 subscription."

Eric Slaats responds:

Your suggestion to use the min/max control to set the statusbar height is really elegant. If the menu height changes, the statusbar height will also change. This solution prevents it, excellent. I'm afraid I can't help you with your C-Set 2.1 problem. I don't own C-Set, and I don't know anyone who does (or anyone who builds programs under OS/2 for that matter). Maybe someone else can address this matter. The problem you've got with the scrollbars really baffles me. When I executed your .EXE file, it clearly showed the transparent area. After recompilation however, it was gone! I wasn't able to invoke the error again. However I've noticed that a PM program can be extremely sensitive to compiler settings. When using the MLE control I couldn't get the find message to work properly. I've tried recompiling examples that worked properly, but it would not work. After toying with the compiler settings after reading about smaller .EXE files, I noticed that these messages worked! Maybe there's a solution here (keep me posted). I've added a the new EDITOR.CPP code (in CUSTOM.ZIP). This new code uses your min/max trick and it is modified so that the ALT key combinations will work. writes:

"Your article in the April '95 edition of EDM/2 ['Building Custom Controls'] has been very helpful. I have one question about the toolbar. In the article you said something to the effect of '...the last menu loaded is the one attached to the frame...' (the same thing is mentioned in a similar example from IBM on Hobbes called FRMSUB.ZIP). However I have run into a difficulty with this. When I press the ALT key (or the combination of ALT-anything) the only menus that respond are the system menu and the toolbar (respond, as in becoming selected or 'indented'). There is no response from the main (text) menu. In fact, the only way to get a response is to use the mouse. If you are aware of this, do you have a solution?

BTW, I tried reversing the loading order of the WinLoadMenu statements, and the program trapped."

Eric Slaats responds:

The ALT thing you've noticed is a bug. I personally never use this feature but (as your messages states) others do. It was rather sloppy to overlook this problem. So I've come up with a solution. (The code is included in CUSTOM1.ZIP). Simply reversing the loading order of the WinLoadMenu statements isn't a solution. The program will trap because the last loaded menu (toolbar) in this case will be handled twice and the menu won't be handled. So how does this new code work?

The first thing we do is (indeed) swapping the WinLoadMenu statements so the Toolbar will be loaded last. This way the toolbar will be loaded last and it will be treated like a regular menu. Next we change the subclass window procedure for the frame window. It must size and place the normal menu window. So where at first the toolbar was handled we will now handle the menu. It is still desirable that the toolbar is placed under the menubar. The toolbar is now placed on top of the client window. So we have to put the menubar on top and replace the toolbar directly underneath it. This is done by the following lines:

     pSWP[usMenu].x = pSWP[usToolbar].x;
     pSWP[usMenu].y = pSWP[usToolbar].y +
                         pSWP[usToolbar].cy -
     pSWP[usToolbar].y = pSWP[usMenu].y - pSWP[usToolbar].cy;

The menubar is placed on top by using the position and cy of the toolbar. (Remember the toolbar has a larger height than the menubar). The last line replaces the toolbar just under the menubar. So now every control has its desired place and the ALT keys will work properly because the PM will attach them to the menubar (highest menu loaded)

The code changes are marked with CODE CHANGE !!!!!!!!!

Kudos and Stuff

Graham TerMarsch ( writes:

"Well, just finished reading EDM/2 volume 3, issue 3, and decided that I've just got to write and tell you a few things...

Firstly, thank you so much for releasing EDM/2. I've searched for, hoarded, handed out, and read every single issue since its beginning and have loved every issue; they were all helpful for something I've been working on.

If you're still accepting snippets, I'm sure I've got a few lying around that I'd send along. I know it might be too little too late and have no excuse for it, but if you'd like some I'd be happy to send them along.

As for what I'd like to see in an upcoming issue, I'll put my vote in with the gentleman who suggested some info on making toolbars and button bars for an application. I've spoken to several developers who all do it different, from creating it as another menu option on the frame to creating a completely new frame control from scratch. In a more broad sense, subclassing of windows would be a really good topic; most everything I'm hung up on right now reflects not knowing how to take proper advantage of window subclasing (especially the frame window). Ok, maybe I'm a bit selfish on this but I'm allowed, it's my suggestion.

I won't babble forever, but will instead thank you and all of the contributors to EDM/2 once again for the service that you've done to all OS/2 developers. I can say that if it wasn't for EDM/2, I probably would've given up on trying to further my PM programming skills and would've just bought a quick and dirty package instead."