Dynamic Screen Manager Directory

Directory .ZIP

objects?






This is pure test stuff for various Dynamic Screen Manager (DSM) APIs. I've never had time to explore these and just recently decided I had to get started. I saw a couple basic samples on the web and realized that a lot of work could be done with just a few APIs. That got me started.

The items are mostly not working programs -- they're only sample CL translations of the API parameters for every one that makes sense in CL. A few cannot be reasonably used in CL because they require pointers within structures (coming soon to an iSeries near you), but those are for pretty advanced features anyway. Until the APIs given here are understood, there's little point in hitting the serious few that are missing.

There are a few working examples that I'm in the middle of playing with to teach myself. I'm putting them here so others might go in different directions and add to the collected experience. I have no idea when I'll have time to continue. If anyone makes progress, we'd all appreciate additions that can be contributed, even if it's notes on experience.

(BTW, Tommy Holden made a suggestion that worked out great in the TSTDSMWIN3 sample. The cleanup of traces of the window seems to be complete. Thanks, Tommy.)

Please read the @GENERAL DISCLAIMER document for any items you should be aware of if you download any of these items.


Sample ILE CLPs

TSTDSMDSP -- Test DSM Display:

This program is my first significant try. It uses the Customer file that IBM ships in the iSeries Access QIWS library and displays a list of the records. I haven't gotten into detailed display field definitions, so only simple character fields from the records are used. I just noticed that I messed up the move of the Customer Number into the Data field I used for moving characters to the display -- the right-justification results in nothing but zeros on the display. If you want to see the numbers, go ahead and fix it. I'll get around to it eventually.

The QCUSTCDT file on my development system only has a dozen records or so, so the logic that handles multi-page lists doesn't come active. But if you make a duplicate of the file and increase the record count, you'll begin to see some sense in how it works. The program displays records a page at a time. What happens when the next page is displayed shows one part of what DSM might give the innovative programmer.

TSTDSMWIN -- Test DSM Window:

This program uses low-level services to define and display a 'window' area on the screen. It's interesting because it doesn't use any 'window' DSM APIs, but goes directly to the command buffer. I don't know if it's useful, just interesting. It also shows a sample of loading a series of display commands to the command buffer and executing them as a group.

TSTDSMWIN2 -- Test DSM Window #2:

This was my first try at a DSM window API. There isn't much here since I soon went to the next version. I have it here just because.

TSTDSMWIN3 -- Test DSM Window #3:

I cloned #2 to start #3 because of some reason I've forgotten. Somewhere along the line, I left #2 behind figuring I'd go back and use #2 for some different future tests.

#3 is focused on a couple DSM window APIs that intrigued me -- move window under user control and resize window under user control. The program defines and displays a window, then gives the user the chance to make the window larger or smaller. It then gives the chance to move the window to another position. At the end, the user can press 'Enter' to loop back and do those again or press F3 and exit.

BTW, if you wonder what the deal is with my choice of characters for borders and corners, I picked various characters so they'd be identifiable on the screen. There are a couple that don't make sense yet; it looks like there are typos in IBM's documentation. (Sheesh... a bunch of these APIs have been around since at least V2R3! Wouldn't you think documentation would be fairly clean? Is this the first site to give good attention to these APIs?)

(This is the 'Tommy Holden' fix area... ) It's easy to tell I haven't finished this one. There's a bug I'm working on that wasn't making sense when I decided to upload all of this to my site. It seems that the underlying DSM environment has been keeping track of the various results of moves and resizes. This can be seen when the program is called again in the same job -- previous window borders become visible as soon as the windowing environment is made active. Makes for a bit of a mess. When I have time to find how to fix it, I'll replace the code on this site. (Who knows when?)

(And the code should now have the fix -- the call to QsnDltEnv at the end was added. The problem was that there was no 'low-level environment handle' to pass in. By passing in the handle to the window instead, it seems to work.)

I got stopped because of what looks like a logical inconsistency either in the APIs or in the documentation. I can't 'delete' my window because the QsnCrtWin documentation says that the low-level environment that holds the window definition must be deleted using QsnDltEnv. QsnDltEnv takes a low-level environment handle to tell it what to delete. Unfortunately, the windowing APIs, such as QsnCrtWin, don't accept a low-level environment handle; they only accept a low-level environment description; no handle is used.

So what 'handle' would be passed to QsnDltEnv? I know from experiment that the default handle doesn't work.

Well, when I find out, it'll get fixed. Until then, take what you want and see what progress you can make. Good luck.