OS/2 Shareware BBS: 14 Text/14-Text.zip/CONTAINR.ZIP/CONTAIN.THD

Text File | 1992-07-25 | 101KB | 2,371 lines

#: 52775 S14/Early Code
    28-Dec-91  07:01:32
Sb: Containers
Fm: Paul Montgomery 71500,3525
To: All

One of the things that would be very usefull to me and I hope to many others
is, example code on how to interact with all of the new controls available in
2.0.  The examples that are present with the toolkit are ok but they are not
complete by any means.  The Styles example gives a quick overview, but doesnt
really delve into any details.  The examples could be in both SOM code and in
regular C code.

The one that I think is the most difficult of the new controls and needs the
most good examples is the one that is used everywhere in 2.0, the container.

For instance, how does one walk the list of RECORDCORE structures that is
present when one has a filled out container. Must one do a CM_QUERYRECORD
every time?  The list seems to be a mixture of 16:16 pointers and 0:32
pointers depending upon when one does the ALLOCRECORD for it.  Must one use
the ALLOCRECORD message to allocate the struct or can one malloc it outside of
the container and pass it in?  Are these the actual structs used by the
container or are copies made when an insert is done?

How does one use the supposed PRECORDCORE that is returned in the
NOTIFYRECORDENTER structure in the CN_ENTER notify id of a WM_CONTROL message.
It aint a valid pointer no matter where I had double clicked.

If we had decent examples up here on IBMOS2, it would help lots of people. I
am willing to do some for notebooks, sliders, and valuesets.  What I need is
examples for the container.  Thanks.

#: 52887 S14/Early Code
    28-Dec-91  18:59:57
Sb: #52775-Containers
Fm: Robert Cannon 73577,127
To: Paul Montgomery 71500,3525

   Well I haven't gotten my EADP kit yet, but containers is about the top of
my list for new things to work with.  Hopefully I'll have it by the end of
next week and maybe we can help each other out.

#: 52900 S14/Early Code
    28-Dec-91  19:58:42
Sb: #52887-Containers
Fm: Mike Kiser 72510,710
To: Robert Cannon 73577,127

Robert, Let me know how your container coding goes and I'll share what I come
up with.....

MIke

#: 52958 S14/Early Code
    29-Dec-91  06:49:02
Sb: #52887-Containers
Fm: Paul Montgomery 71500,3525
To: Robert Cannon 73577,127

The interesting thing about containers that I see so far is the difference in
the way that one works with them from the start.  No other control that I am
aware of makes you allocate the struct you are going to use through a message
to the control.  And then you get to fill out the returned value. It also
supposedly passes a lot more info back to the owner when an action occurs.
There doesnt seem to be a need for the Queryselected type of interaction one
has to use with a list box.

Keep us informed as to your progress.

#: 52899 S14/Early Code
    28-Dec-91  19:57:22
Sb: #52775-Containers
Fm: Mike Kiser 72510,710
To: Paul Montgomery 71500,3525

Paul, I feel the same way; the samples in the new Toolkit are VERY poor in the
areas of creating Notebooks, Folders, Containers.  I am currently attempting
to code a container, slider, a "flashing" (background) Folder, etc. however,
there is very very little to go on as a "guide".  I guess the trial and error
method is the best way for learning, but not for meeting a strict time
schedule.  The "animal" and "car" SOM samples are very disappointing
also......I was expecting a little more than just simple text mode characters
stating "Woof Woof"!!

MIke PS.  Most of the samples are just recompiled samples of the original MS
SDK.....nothing new there!!

#: 52916 S14/Early Code
    28-Dec-91  20:50:05
Sb: #52899-Containers
Fm: Guy Scharf [Sysop] 76702,557
To: Mike Kiser 72510,710

Mike,

Sliders are pretty easy.  If you want, I can send you a sample.  It will
probably take a day for me to get it working under the latest drop.  I'll be
tackling containers soon myself.

Guy

#: 52959 S14/Early Code
    29-Dec-91  06:49:08
Sb: #52899-Containers
Fm: Paul Montgomery 71500,3525
To: Mike Kiser 72510,710

It is a beta of the toolkit also. <grin>.

The example called "styles" gives a limited example of all of the new
controls, but it is by no means complete.

BTW one technique that works real well with a notebook is to create each page
with the dialog box editor and then do a WinLoadDialog to create the window
before you associate it with the page.  You still have to write
sizing/positioning logic, but it is much easier to get initial positions
right.  Look at Petzolds HexCalc code for an example of using the
WinLoadDialog function.

#: 53084 S14/Early Code
    29-Dec-91  20:55:42
Sb: #52959-Containers
Fm: Mike Kiser 72510,710
To: Paul Montgomery 71500,3525

Paul, Thanks for the tip.  I'll check it out...

MIke

#: 53036 S14/Early Code
    29-Dec-91  15:46:18
Sb: #52994-Containers
Fm: Paul Montgomery 71500,3525
To: Guy Scharf [Sysop] 76702,557

> Haven't tried

> Dont know,

We seem to be working with the same stuff <grin>...  At least its nice to be
back into a steep learning curve again.  1.3 was getting old hat. <grin>
(yeah, right)  Betas to the left of me Betas to the right.  At least the
hardware I am working on is almost stable.

I should have answers to the presparam stuff next week.  I probably wont get
to the owner draw stuff by then.  Too much container stuff to play with.

#: 53083 S14/Early Code
    29-Dec-91  20:54:10
Sb: #53036-Containers
Fm: Mike Kiser 72510,710
To: Paul Montgomery 71500,3525

Have either one of you guys gotten the WPCAR sample to compile yet? I've
worked on it ALL weekend and haven't been sucessful....

Thanx! MIke

PS. Does anyone know what the "new" 32-bit macro for MOUSEMSG(&msg)->x is?? I
can't get an app that I've just ported from 16 to 32-bit to compile due to the
C Set/2 compiler kicking this one out......

#: 53163 S14/Early Code
    30-Dec-91  05:26:44
Sb: #53083-Containers
Fm: Paul Montgomery 71500,3525
To: Mike Kiser 72510,710

I havent played with the SOM examples yet.  I have a tight deadline that
doesnt have SOM learning curve in it.  That will have to wait for release 2.
Then I expect you guys with the arrows in your back will be able to help. What
I am concentrating on now is how to interact with the controls from a non SOM
application.

#: 53340 S14/Early Code
    30-Dec-91  21:20:34
Sb: #53163-Containers
Fm: Mike Kiser 72510,710
To: Paul Montgomery 71500,3525

This SOM learning curve looks tremendous! Much more complex than "just"
PM......

MIke

#: 53399 S14/Early Code
    31-Dec-91  05:26:44
Sb: #53340-Containers
Fm: Paul Montgomery 71500,3525
To: Mike Kiser 72510,710

I did a quick look at it.  It looks like it is a healthy learning curve to
understand the syntax.  The learning curve I am really worried about is the
"how do I design a non-trivial app with this thing" one.  I can get the syntax
from the manuals, the design aspects come from trial and error over time.
Very few manuals talk about design concepts and application of those concepts
in non-trivial excercises.

#: 62284 S4/Version 2.x
    30-Jan-92  04:19:15
Sb: 177 containers
Fm: Paul Montgomery 71500,3525
To: Brian Proffit[Sysop] 75300,1466

Brian
  We just got the 177 toolkit from our SE and its real neat except for one
leeeetle thing.  The mechanism we used under 167 to add records to a container
as shown in the "Styles" example doesnt work any more.  And we havent a clue
yet as to why.  The example provided with 177 doesnt work either.  Its obvious
that containers DO work, but the question is how?

Is there a list of changes between the 167 and 177 programatic interfaces
anywhere in the toolkit that I have missed?  If not, is there anyway that
someone can provide such a list so that we dont waste a lot of time trying to
track down these things?  Irv? Mel?

#: 66226 S4/Version 2.x
    12-Feb-92  13:57:44
Sb: #65888-Anybody using SOM
Fm: Frank Mena 73507,3610
To: Mike Kiser 72510,710

None so far.  I trying to figure out how to use the WPS calls without using
SOM.  By the look of the WPS api, all we have to do is figure out how to make
and pass the "SOMSelf" structure.  This way I can replace the SOM class
hierarchy with a set of C++ classes that provide at least the same amount of
functionality.  I guess this would be the same thing as C++ SOM bindings.

BTW, after in installed the CAR sample and re-booted,  the icon changes to a
big read circle with the yellow letters "FS" in them. When I activate the app,
I get a window, but no car.  THe settings pages and menu items (beep horn) are
no longer there.  I tried removing the class, re-booting, then re-installing
but no dice.  Did you notice that you can beep the horn without starting the
app?

It appears to me that a WPS app effectively becomes an extension of the WPS.
I also heard the WPS apps are in the same address space as the WPS, so that
there is no protection from each other.  If that is true, I don't know if I
want to write my app as a WPS app, just make it look like it.

Did you actually use any of the wpXX calls from the "Workplace Objects and
Functions" manual?  I've been trying to create a container on top of the
client area, but I can't get it to work.  The sample program has one working
within a dialog box, but I need to place one in the client area on my main
window.  Have you had any luck with this control?

I would like to share more with you our experiences with SOM and WPS.

Thanks, Frank.

#: 67341 S4/Version 2.x
    15-Feb-92  10:04:10
Sb: #Anybody using SOM
Fm: Steve Woodward 76525,1266
To: Mike Kiser 72510,710 (X)

The CUA controls - Slider, container, Valueset etc... are all accesible as PM
window classes, you do not have to use SOM or the WPS METHODS to utilize these
controls.

Steve woodward - OS/2 PM Development

#: 67564 S4/Version 2.x
    15-Feb-92  19:42:22
Sb: #67341-Anybody using SOM
Fm: Bernard Tiffany 75046,2667
To: Steve Woodward 76525,1266 (X)

The new OS/2 2.0 controls such as sliders, containers, notebooks, value sets,
plus file and font dialogs are all described in IBM Personal Systems,
Developer, No. 1, 1992. SOM is described in "Object-Oriented Programming," in
the same issue, too.

LBT.

#: 67519 S4/Version 2.x
    15-Feb-92  17:56:54
Sb: #67379-Anybody using SOM
Fm: Frank Mena 73507,3610
To: James F. Lederer 74030,20 (X)

James, thats what I was thinking, but then Steve Woodward pointed out
something that puts a wrench into that.  If I try to create a desktop folder
inside of one of my containers, I can only do that if my app resides within
the WPS process.  Of course, you might ask why I don;t just create a container
with a folder icon.  An example would be trying to add an outbasket object
(ala the CUA 91 demo) inside of my app container or folder.  The outbasket is
within the WPS process....  You know what?  I think i'm even confusing
myself...  I think I better sit down and give this some thought.  Its a new
premise that I haven't given enough thought to yet.  I wish we had a WPS
programmers guide.

#: 67521 S4/Version 2.x
    15-Feb-92  17:57:01
Sb: #67311-Anybody using SOM
Fm: Frank Mena 73507,3610
To: Gary Murphy 73457,365 (X)

Do you know if they added any of the other container views beside icon, tree
and details?

#: 68057 S4/Version 2.x
    17-Feb-92  08:19:02
Sb: Anybody using SOM
Fm: David Moskowitz 76701,100
To: Frank Mena 73507,3610

Frank, I haven't been able to get WPS containers in the client area, either.

If you want to use C++ classes, I suspect the best thing to do is encapsulate
SOM objects with the C++ classes

I'm told John Pompeii of Objective Solutions is on the way to making this
work.  His product, Object/PM is an EXCELLENT class library for OS/2!

David

#: 68131 S4/Version 2.x
    17-Feb-92  11:37:25
Sb: #68057-Anybody using SOM
Fm: Frank Mena 73507,3610
To: David Moskowitz 76701,100

It turns out that with the changes to 177, you have to memset to zero the
container structures abd make sure to set the cb field.

I know about John.  I talk to him on a weekly basis exchanging experiences
with the WPS.  I also have Object:PM.

#: 69197 S4/Version 2.x
    19-Feb-92  19:42:32
Sb: #68291-Anybody using SOM
Fm: Steve Woodward 76525,1266
To: Frank Mena 73507,3610

Just open up the drive the desktop is contained on and drag it (or use the
pop-up Move menu item) to the drive you want it on.

also, there's a statement in ini.rc that you could modify BEFORE install takes
place (or delete \DESKTOP and below - erase your old OS2.INI and run MAKEINI
after changing the statement to point to a specific drive.

the statement below allows install on the boot drive:

  "PM_InstallObject" "Desktop;WPDesktop;?:\" "OBJECTID=<WP_DESKTOP>"

change ?:\ to d:\ to get it to install on your D; drive.


Steve Woodward - IBM OS/2 PM Dev.

#: 70629 S4/Version 2.x
    23-Feb-92  13:24:17
Sb: Anybody using SOM
Fm: Steve Woodward 76525,1266
To: Frank Mena 73507,3610

Just open up the drive the desktop is contained on and drag it (or use the
pop-up Move menu item) to the drive you want it on.

also, there's a statement in ini.rc that you could modify BEFORE install takes
place (or delete \DESKTOP and below - erase your old OS2.INI and run MAKEINI
after changing the statement to point to a specific drive.

the statement below allows install on the boot drive:

  "PM_InstallObject" "Desktop;WPDesktop;?:\" "OBJECTID=<WP_DESKTOP>"

change ?:\ to d:\ to get it to install on your D; drive.


Steve Woodward - IBM OS/2 PM Dev.

#: 67351 S4/Version 2.x
    15-Feb-92  10:25:32
Sb: #6.177 and WC_CONTAINER
Fm: Rick Fishman 72251,750
To: All

It seems that 6.177 has changed the interface to the container control a bit.
Now my CM_INSERTRECORD message gets an access violation. The only difference
between my 6.167 code and this is that now I initialize the recordInsert.cb
variable to sizeof( RECORDINSERT ). In 6.167 it was not necessary to init the
cb field. Under 6.177 sending the CM_INSERTRECORD message gets a 1208 return
code (PMERR_INVALID_PARAMETERS) without doing this.

I also noticed that the STYLE sample program in the toolkit has the same
problem in that when you bring up the container the icon that used to show up
under 6.167 no longer shows up - I imagine its CM_INSERTRECORD message is
failing. Maybe the reason it doesn't get an access violation is that I am
bringing mine up in detail mode while it is using icon mode.

Has anyone else had this problem? If so, any workarounds been found? Obviously
the container is still working. I think WPS would have a few problems if not
:- )

Rick

#: 67434 S4/Version 2.x
    15-Feb-92  13:09:37
Sb: #67351-#6.177 and WC_CONTAINER
Fm: Robert Cannon 73577,127
To: Rick Fishman 72251,750 (X)

   I noticed that some of the container structures have changed since 6.167.
For one thing, RECORDINSERT structures now have the .cb field where they
didn't before.  I haven't had a chance to get my old code working yet (or to
even look at it for more than 30 minutes).  The best thing to do is to print
the PMSTDDLG.H file to see what the structures look like now.  Be sure and
initialize everything in the strucutre to something.

#: 67602 S4/Version 2.x
    15-Feb-92  22:21:17
Sb: #67434-6.177 and WC_CONTAINER
Fm: Rick Fishman 72251,750
To: Robert Cannon 73577,127

Robert,

 >Be sure and initialize everything in the strucutre to something.

You called it. I bypassed my usual habit of memset'ing my structures to zeroes
(I've GOT to defend my silly mistakes <g>). Got to do that besides filling in
the .cb field as a pRecordParent struct pointer was added.

Thanks.

Rick

#: 67606 S4/Version 2.x
    15-Feb-92  22:28:18
Sb: #67434-6.177 and WC_CONTAINER
Fm: Mike Kiser 72510,710
To: Robert Cannon 73577,127

Robert, My Slider control isn't working properly under 6.177 ( in fact, it's
not showing up on the window at all).  I compiled it with the 6.167 tools and
have not had the time to recompile it with the 6.177 C Set/2 compiler.  I am
just hoping (fingers crossed) that the Slider control will reappear.

MIke

#: 69086 S4/Version 2.x
    19-Feb-92  16:41:35
Sb: #67606-6.177 and WC_CONTAINER
Fm: Robert Cannon 73577,127
To: Mike Kiser 72510,710

>>showing up on the window at all).  I compiled it with the 6.167 tools and
have not had the time to recompile it with the 6.177 C Set/2 compiler.  I am
just hoping (fingers crossed) that the Slider control will reappear.

   One of the changes between 6.167 and 6.177 is that the actual number of
many of the new PM messages have been changed.  This probably has a great deal
to do with your problem.  Recompiling with the new toolkit should solve the
problem.  Be on the lookout for changes in the structures that are passed to
the control, also.

#: 72387 S14/Early Code
    27-Feb-92  23:16:18
Sb: #Container Problems
Fm: Wayne Kovsky 76164,3504
To: All

I am having a problem using Containers with the 6.177 toolkit.  I can create
the container, describe record fields, load records, and display those records
in Icon, Name and Text formats.  However, if I try to display them in Detail
format, I get an addressing exception.  My app defines column headings
(including column widths) for the fields, as well as the location of the last
field to left of the split bar, and the location of the split bar itself.
Here is where it gets interesting ...

If I never load any records into the container, but switch to Detail format, I
get a display with all column headings and column separators, and with the
split bar just where I wanted it.  Once in this mode, if I try to load records
(or if records are already loaded), addressing exception!  Now, if I omit the
"last field to left of split bar" but include the location of the split bar, I
get a screen that has a container title, the split bar, and scroll bars, but
no records and no column headings or separators (but no crash, either).  I can
go back to any other view, and see all records just fine.

Next, if I include the "last field to left of split bar" address, but omit the
location of the split bar, I get no column headings, no column separators, no
split bar, and no records (and no crash).  Again, going back to other views
still works just fine.

This is all on 6.177; I am getting 6.304 system and toolkit tomorrow, so
perhaps this is a container DLL bug and all will be well ... but in case it
isn't, any ideas on what to look at?  (BTW, the example STYLE program omits
some structure size settings that cause it to fail if you recompile it; easy
to fix once you know what to look for.)

#: 72673 S14/Early Code
    28-Feb-92  15:53:05
Sb: #72387-Container Problems
Fm: Robert Cannon 73577,127
To: Wayne Kovsky 76164,3504 (X)

   I am still working with Containers myself, but it sounds like the problem
is in the allcoation or the setting of fields in the FIELDINFO structure. Make
sure the offset parameter isn't pointing past the end of your RECORCORE
structure and also make sure when you allocate RECORDCORE structures that you
allocate enough extra memory to hold you detail data.

#: 73066 S14/Early Code
    29-Feb-92  16:03:24
Sb: #72673-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Robert Cannon 73577,127

Thanks for your reply, Robert.  I am allocating the RECORDCORE structure in
the manner used in the 'style' sample program:  that is, the RECORDCORE
structure is the first element in my own USER_RECORD structure, and I tell the
container to allocate extra memory that is the size of my USER_RECORD
structure minus the size of the RECORDCORE structure, as in the sample code.

I have used IPMD to look at every address in all of the relevant structures,
and they all look good to me.  The abort is coming in the container DLL
itself, not in my code; I can format these records just fine, and I can (and
do) access data in them in other parts of my application, so I am fairly sure
that pointers and data lengths and offsets are OK.

Meanwhile, back to IPMD ...

#: 73464 S14/Early Code
    01-Mar-92  16:15:51
Sb: #73066-Container Problems
Fm: Paul Montgomery 71500,3525
To: Wayne Kovsky 76164,3504

Wayne,
  Check PMSTDDLG for the typedef of the structs you use when creating the
columns.  You will notice a few new fields that the styles example doesnt fill
out.  Make sure you do!  If you notice, the styles example doesnt work as
coded under 177 either. <grin>

Paul Montgomery

#: 73706 S14/Early Code
    02-Mar-92  10:23:33
Sb: #73464-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Paul Montgomery 71500,3525

Yes, Paul, I had noticed that the styles example didn't work for containers; I
posted a message to Ian Ameline separately detailing how to fix that.  I have
looked at the pmstddlg.h file exhaustively, and am filling in (or have
verified that the system properly filled in) every field defined in all of the
structures I am using.  (I have looked at these fields both from the point of
view of my source code, and also during execution via IPMD.)

I am pretty certain that one of these fields, in one of these structures, is
precisely my problem:  I have it wrong somewhere.  Troubl is, I don't know
where to look, that I haven't already looked with as much care as I can
muster.  I am also certain that this is going to be a real head-slapper when I
find it ...

One other thing that I do, that the styles example does not, is check EVERY
return code from EVERY function call; I get no errors on anything related to
containers (or anything else, for that matter) that do not get reported.  I
have also chained through the record structure and printed every field, and
the contents of every container-related structure at various steps in
creating/filling/displaying the container.  Everything I do with containers
(which by now, is a lot) works except displaying detail views, and sorting (a
separate message on this subject).  Whatever I am doing wrong seems to affect
only the detail view of the records, since the other views can obviously chain
through the records correctly.

C'mon, somebody help me slap my forehead!

#: 73991 S14/Early Code
    02-Mar-92  20:51:48
Sb: #73706-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, just a thought. I had a similar experience with the details view of a
container. This may have *nothing* in common with yours, though.

On the CM_INSERTDETAILFIELDINFO message, each FIELDINFO structure in the array
contains an offStruct member. For strings (CFA_STRING) this is set up as
FIELDOFFSET( STRUCT, psz ). My mistake was in thinking that I could set up a
USERRECORD like this:

   typedef struct _USERRECORD
   {
        RECORDCORE rc;
        CHAR szString[ 100 ];
    } USERRECORD;

and set fieldinfo.offStruct = FIELDOFFSET( USERRECORD, szString ).

What I had to do was this:

   typedef struct _USERRECORD
   {
        RECORDCORE rc;
        PSZ szString;
        CHAR achString[ 100 ];
    } USERRECORD;

 Then:

   userrec.szString = userrec.achString;
   fieldinfo.offStruct = userrec.szString;

   or malloc the memory and use that address in the offStruct field.

It was obvious once I looked closely but trying to follow the Style sample
made me stupid. I imagine you didn't make this same mistake. FWIW.

Rick

#: 74436 S14/Early Code
    03-Mar-92  19:20:29
Sb: #73991-#Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Rick, you may have hit it ... as soon as I finish this reply, I am going to
try your method.

If I understood your posting correctly, it could be boiled down into the
following statement:  "In the FIELDINFO structure, the 'offStruct' field must
contain an offset to a <POINTER TO> the string, not an offset to the string
itself."  In all my poring over the documentation and examples, I never came
across anything that would have led me to believe that.  You say it was
obvious once you looked closely, so I imagine that will be true for me as well
-- and I will, as promised, slap my forehead, and perhaps even acknowledge
that my ex-mother-in-law's beliefs about the limitations of my intelligence
and my questionable parentage were not entirely inaccurate ...

If this thing really needs an offset to a pointer, then I sure understand why
it was blowing up.  I should have this working in less than an hour!!! Thank
you, thank you, thank you!!!  (In advance, and awaiting only confirmation.)
Wayne

#: 74463 S14/Early Code
    03-Mar-92  19:51:09
Sb: #74436-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504 (X)

Wayne, that IS what I meant. I hope it works out for you. What was happening
as you pointed out is it was taking the first 4 bytes of the string as the
address of the string and trapping. It seems that a "USERRECORD" structure
really requires some thought. I decided to use the CM_ALLOCRECORD message to
allocate just enough memory for all my strings as well as pointers to them.

So with 3 strings it looks like this:

  typedef struct _USERRECORD
  {
      RECORDCORE rc;
      PSZ pszString1;
      PSZ pszString2;
      PSZ pszString3;
  } USERRECORD;

My actual strings are lined up after pszString3 one after another. The 'psz'
prefix really applies in this case (as opposed to 'sz').

Hope your head is alright<g>. I can hear the slapping from here. If I remember
correctly, that's where my big whelts (sp?) came from 2 weeks ago<g>.

Rick

#: 74488 S14/Early Code
    03-Mar-92  20:41:50
Sb: #73991-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, I just made the changes required and tried it, and boy, am I a happy
camper!!!  I now have about 14 fields, neatly lined up in columns, to go with
my records.

I went back and looked at the sample program.  It has a single CMA_STRING
field, but it is indeed a poiner to the actual string somewhere else; don't
know how I missed that (he said, slapping his forehead).  I also looked
briefly at the documentation, and didn't (yet) see anything that would have
put me onto this.

I also tried showing some other field types (CMA_DATE and CMA_TIME, plus a
ULONG), but they still blow.  I'll bet I will find out why within a few more
minutes.  I just had to get back here to let you know that you solved the
problem.

If you are ever in Colorado, let me know; I owe you a beer!

#: 74893 S14/Early Code
    04-Mar-92  19:44:03
Sb: #73991-#Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Rick, I have been working with detailed container data all day now; life is
good again!

Well, almost ... I have no problem with CFA_STRING, CFA_DATE, CFA_TIME, and I
don't use CFA_BITMAPORICON.  But I still get an abort with CFA_ULONG (you
would think this would be one of the really 'easy' data types, among that
list).

I tried making a pointer to the ULONG (as I did for the strings), and I tried
using just the offset to the ULONG itself directly (as is required for the
date and time fields -- don't you love consistency in an API?).  Are you using
this type, and if so, what is the magic incantation?

#: 74933 S14/Early Code
    04-Mar-92  20:43:07
Sb: #74893-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, I hadn't tried using a CFA_ULONG column yet. I just tried it and got an
access violation. I can't imagine that you'd need a POINTER to the ULONG. I
agree with you that since it is simply a 4-byte value that it must be the same
as a CDATE and CTIME column in that respect.

I'm going to send off a question via MCI Mail and see what happens. I'll let
you know what I find out. It may be a couple of days...

Glad to see everything else is working for you though. Hope to take you up on
that beer sometime...

Rick

#: 75323 S14/Early Code
    05-Mar-92  21:13:19
Sb: #74933-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Well, I never thought I would be happy to hear about someone else getting an
access violation; no offense, but this is good news!  I was beginning to think
my toolkit had some code like 'if KOVSKY then (PVOID) 0 = 12345'. (What, me
paranoid?  I don't have time to be paranoid, with all these guys out to get
me.)

I just got 6.304 up today; you didn't mention what you are running, but I will
try again with this tonight.  (I am also getting the same thing with the PVOID
address that I pass to CM_SORTRECORD, but which comes back to me as nothing I
recognize.  I hope this is a toolkit problem too.)  If this works on 6.304, I
will let you know.

#: 75338 S14/Early Code
    05-Mar-92  21:58:00
Sb: #74933-#Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Rick, I now know that you are using 6.177, not 6.304, since I just tested
CFA_ULONG under 6.304:  it works!  My favorite kind of bug fix ("Just install
these new tools, recompile, and go out into the world and be fruitful and
multiply").

CM_SORTRECORD remains broken, however.  I had thought that only the third
parameter (a PVOID that you can pass to the CM_SORTRECORD, which in turn is
passed to your 'compare ()' function) was trashed, because it happened to
cause me to blow up before I looked at the other two (pointers to records to
be compared).  Turns out all three are garbage, when I looked closer.

Ah, well, I guess I'll move back to notebook controls for awhile; I had some
bugs there that I believe were bugs in 6.167, and haven't looked at them
since.  Except for sorting, containers looks pretty solid now.

#: 75360 S14/Early Code
    05-Mar-92  23:20:36
Sb: #75338-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, great news about CFA_ULONG. I haven't heard back from MCI Mail but I
guess they'll tell me to install the new toolkit (just got it today but won't
have a chance to install until Sunday).

I haven't used CM_SORTRECORD yet as I sort all records before inserting them
into my container. I'll try it too if I get a chance.

Good luck on the notebooks. That was my next project. Isn't it great to be
pioneering this stuff <head turning a full 360 degrees<g>>. I'll tell you
though - even with the bugs we've found - these new controls are pretty
impressive.

Off to back up before Michaelangelo strikes....

Rick

#: 75595 S14/Early Code
    06-Mar-92  19:52:42
Sb: #75360-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

I insert my records in sorted order as well, Rick, but I also allow the user
to sort however they like (the records have about 17 fields or so, and all but
a couple of them are sensible candidates for sorting).

I have already gotten pretty far with notebooks:  multiple pages, major and
minor tabs, a sensible way to load the numerous dialogs involved (to improve
response time), etc.; I am using just about every message and notification.  I
have one really BIG problem, though:  each of my pages is a dialog (the dialog
already works in my old usage, which I have kept in the program).  Hitting a
control on a dialog on any given page works; changing to a different page and
hitting a control there works.  But if you return to a page where a control
has been hit already, and try to hit a second control, GP fault time
(definitely NOT to be confused with Miller time).

I haven't tried this yet under 6.304, and I am hoping (against hope) that this
is a now-fixed toolkit problem.   My old forehead can't stand another might
slap ...

#: 75655 S14/Early Code
    07-Mar-92  01:12:17
Sb: #75595-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

It sounds like I will be using the notebook control in the same way, i.e.
multiple dialog boxes rather than using WinCreateWindows for the controls. I
am porting a 1.3 PM program that needs gobs of info from the user to set up an
entry. I'm hoping the notebook control will do the trick. In the 1.3 version
the user has to bring up 3 separate dialog boxes and hit ok on all - not
great.

I hope your problem is fixed under 6.304. Your sacrifice pre-6.304 is greatly
appreciated <g>. I haven't heard of a lot of problems with notebooks though -
THAT's encouraging. Think I'll put on a helmet though - my forehead can't
handle that many more slaps...

#: 76203 S14/Early Code
    08-Mar-92  14:45:44
Sb: #75655-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, I have some great news on my Notebook problems.  First, 6.304 did NOT
automagically solve them; but blood, sweat and tears did.

The "magic pill" is to take great care on setting the owner window when you do
your 'WinLoadDlg ()' for the dialog(s) that will be the notebook page(s). I
was using a client window that started a notebook window that was a dialog,
and the notebook dialog was loading the page dialogs.  I was using
'HWND_DESKTOP' for the parent of the page dialogs, and the notebook's hwnd as
the owner.  Again, the symptom was that I could only touch one control on any
given notebook page; when I touched a second control (or touched the first one
again) on any page, the whole thing crashed (dropping me back to an OS/2
prompt).

I tried setting hwndOwner to NULLHANDLE, and this worked!  However, it caused
me other problems, since I was doing things in other areas that required
getting the owner handle.  With this clue, I then tried setting hwndOwner not
to the Notebook dialog hwnd, but to the client window's hwnd; this works!

Hey, with ll the time I just saved you, now we owe each OTHER a beer!

#: 76678 S14/Early Code
    09-Mar-92  19:08:58
Sb: #76203-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

 >Hey, with all the time I just saved you, now we owe each OTHER a beer!

A beer?! I think it's time to start resorting to tequila! Great catch! The
problem with the container and notebook controls is that when you have a bug
with them it takes forever to describe the problem to someone else so you can
get help.

I printed your message out lest I forget it.

 >I was using a client window that started a notebook window that was a
dialog.

Pardon my notebook ignorance, but what do you mean by 'a notebook window that
was a dialog'? Do you mean a notebook control that fills a dialog box, a
notebook control that fills the client window, or is it actually possible to
define a 'notebook dialog'? I've been thinking about how to present the
notebook so this is intriguing.

Thanks for keeping me informed.

Rick

#: 76740 S14/Early Code
    09-Mar-92  21:49:29
Sb: #76678-Container Problems
Fm: Frank Castellucci 72261,2700
To: Rick Fishman 72251,750

Rick, I've been goofing around with notebook controls:

Notebooks can contain pages. Pages are child windows of the notebook. Pages
can contain any control a normal window or dialog box can contain, sliders,
buttons, static, etc... I am using multiple pages of a notebook to remove
nested dialog windows, much cleaner!

Don't know if any of that helps, my opinion based on use.

Frank

#: 77052 S14/Early Code
    10-Mar-92  19:33:57
Sb: #76740-Container Problems
Fm: Rick Fishman 72251,750
To: Frank Castellucci 72261,2700

Frank, thanks for your comments on notebook controls. My next project is to do
much the same as you are describing - replacing nested dialogs. I'd like to
see the STYLE sample use dialogs for pages so as to dictate a clean way to do
it. I'm imagining that doing WinLoadDlgs for the pages at program
initialization is the best way. Is that what you did? Did you put the notebook
control itself in a Client window or in a dialog box (anything nonCUA about a
notebook in a modal dialog box)?

Rick <guess you can tell my mind is thinking but I haven't yet started the
coding<g>>

#: 77058 S14/Early Code
    10-Mar-92  20:06:35
Sb: #77052-Container Problems
Fm: Frank Castellucci 72261,2700
To: Rick Fishman 72251,750


Rick, > that doing WinLoadDlgs for the pages... Is that what you did?

I forget, I have to check back to the code. Will upload sample for you if you
want.

> Did you put the notebook control itself in a Client window or in a dialog

Both.

Guess you can tell my mind was coding but I haven't yet started thinking<g>.

I have at this point totally fragged the development machine between mixing
and re-mixing various version of the OS, CSET2, drivers, production code,
sample code, experimental code, blah blah blah... Just received the latest
driver for the OS and am waiting for the tools to straighten things out.

Frank

#: 77428 S14/Early Code
    11-Mar-92  19:09:40
Sb: #77058-Container Problems
Fm: Rick Fishman 72251,750
To: Frank Castellucci 72261,2700

Frank, I appreciate the add'l info on the notebook. When I start coding I'll
probably have some more to ask/share.

 >I have at this point totally fragged the development machine between mixing
and
 >re-mixing various version of the OS, CSET2, drivers, production code, sample
code,
 >experimental code, blah blah blah...

Boy, don't I know...I'll be glad come GA (well maybe a month later<g>) when I
can start making more room on my hard disk. 210 megs ain't as much as it used
to be - especially with all 2.0's flavors, 1.3 and toolkit, MSC, C Set/2,
Zortech, etc, etc, etc.

Rick

#: 77115 S14/Early Code
    10-Mar-92  23:02:29
Sb: #77052-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, you probably DON'T want to do 'WinLoadDlg ()' for each of the pages
during notebook initialization, unless you have a VERY small number of pages.
Creating (inserting) the pages is relatively time-consuming as it is (that is,
if you do nothing but create empty pages -- try it for, say, 20 or so pages,
and you'll see).  If you additionally do 'WinLoadDlg ()' for each page, you
will get a variety of messages sent to each dialog, specifically including
'WM_INITDLG', so a lot of processing could go on before your user sees the
first notebook page dislayed.

I defer loading the page's dialog until the first time that page is accessed.
You get a message from the notebook control (BKN_PAGESELECTED), telling you
when a page is being made the current page (the message contains the old and
new page ID's).  I check to see if the dialog has been loaded yet, and if not,
I load it then.

In my use of notebooks (for settings), it is likely that at any given time, a
user might touch only a couple of the pages, but I have somewhere between 15
and 20 of them, so I can save the user a fair amount of time by only loading
the ones he wants to see.  I keep a structure per page, with some status
information that helps in stuff like this; it also helps in cleanup (in case
of abnormal exit at that point, from the entire program).

Tequila sounds good -- Jose Cuervas Gold?  Alternately, you could give me some
tips on the Container sorting problem that has me blocked right now... And,
isn't it time a new section, "OS/2 2.x Programming", got started???

#: 77427 S14/Early Code
    11-Mar-92  19:09:33
Sb: #77115-Container Problems
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, good advice on not loading the dialogs (that will be used as pages) all
at once. Even though the notebook I am going to do is only 3 pages so far, it
could grow and then I'd have to change my algorithm.

 >Alternately, you could give me some tips on the Container sorting problem
that has
 >me blocked right now...

I'm going to try and use CM_SORTRECORD in the next couple of days...I'll let
you know how it goes.

I agree about the "OS/2 2.x Programming" section. It seems like that would be
really popular! You'd at least have a 'Container' thread and a 'Notebook'
thread - even if 2 of the participants reeked of tequila and shlurred their
words<g>!

#: 77114 S14/Early Code
    10-Mar-92  23:02:18
Sb: #76740-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Frank Castellucci 72261,2700

Frank, I agree; I am using all the controls you mentioned, and then some, in
notebooks.  Only things I am NOT using are containers (I am using them, but
not in a notebook) and selection sets.  I am even using the new fonts dialog
as a page in a notebook (the trick here is having a notebook page that is
large enough for it ...)

I had a LOT of trouble with notebooks when they first became available
(6.149???), but 6.177 fixed most of my problems, and 6.304 (and my recent
discovery about the importance of the owner window) solved the rest.  There
are a few things you have to do (via trial and error) to get "sensible"
behavior out of notebooks in some cases, and a few more things you have to do
to get decent performance (in particular, bringing up the notebook in the
first place), but all in all, this is (now, at least) a stable and eminently
usable control.

Containers are still a little behind this state of being, unfortunately ...

#: 77146 S14/Early Code
    11-Mar-92  04:39:52
Sb: #77114-Container Problems
Fm: Frank Castellucci 72261,2700
To: Wayne Kovsky 76164,3504


Not to mention we have de-railed the topic of this thread.

Containers, the most immediate use I can see would be to present application
specific objects ( files, etc.. ) to the user, with a value set tool kit
nearby somewhere so the object in the container can be dragged over a tool in
the value set. I don't have CUA'91 yet so I don't know if this is valid as far
as that goes.

BTW: The latest IBM Personal Develop mag has example of all the new controls
with example code for each, EXCEPT CONTAINERS!

It also includes the DAP letter to upgrade to .177, I got a kick out of this
one, someones a tad behind the times sending this stuff out so late.

Frank V. Castellucci C.O.L. Systems Inc.

#: 77113 S14/Early Code
    10-Mar-92  23:02:11
Sb: #76678-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Sorry I wasn't too clear, but it is a little hard to explain.  I have a client
window that is "vanilla" (like any client window you ever saw).  If you ask
that window (via a menu selection) to bring up "Settings", it loads a dialog
-- the dialog happens to be a notebook control, which you can define via
'dlgedit'.  The notebook control/dialog needs a fair amount of additional work
to be useful -- you have to load the pages, establish the size of the tabs,
insert page text, etc.  You could load the notebook as another window, rather
than as a dialog (that is, you could use 'WinCreateWindow ()' instead of
'WinLoadDlg ()'), and in fact there are some advantages to doing this, at
least in my app, so I am likely to switch.

All of this knowledge is "bleeding edge of technology" stuff; if there is any
documentation or examples (or even mentions) of using dialogs as pages in a
notebook (instead of canned text and/or icons, as in the toolkit example), I
haven't run across it.  I ran into all kinds of weirdness as I worked my way
through this; some of it was simply bugs in the early drivers (that is, I did
nothing to change weird behavior, but it went away with later compiles).  Some
of it is poor design (in particular, the way you manage pages with both major
and minor tabs); and some of it is incomplete documentation (the "owner
window" stuff, for example).  I have discovered a ton of "tricks", but
honestly I don't recall them any more.  If you run into any stumbling blocks,
send me a message; I have some pretty complex dialogs working now in my
settings notebook, and I am using just about every feature of notebooks,
successfully at last.

#: 75374 S14/Early Code
    06-Mar-92  00:18:41
Sb: #75338-Container Problems
Fm: Adam Goodman 100021,3161
To: Wayne Kovsky 76164,3504

Wayne,
As you say you are moving back to notebooks controls, I'd draw your attention
to the minor piece of confusion I posted 03/04/92 as "BKA_MAJOR (NBOOK
REGION)".  You'd probably already spotted it, and it is in an early version
(6.167):
Online help says to use BKA_MAJOR/BKA_MINOR to set dimensions of tabs, but the
header file has BKA_MAJORTAB / BKA_MINORTAB.
If you get a moment can you tell me whether this has been sorted out in later
releases,
Exciting, isn't it?!...

#: 75593 S14/Early Code
    06-Mar-92  19:52:23
Sb: #75374-#Container Problems
Fm: Wayne Kovsky 76164,3504
To: Adam Goodman 100021,3161

Adam, I had spotted that on-line documentation problem when I first got 6.167.
I reported it at the time, but I just checked and ... it is still wrong.

I have been using notebook controls since I first got 6.167, but  I have a
number of strange problems with them.  Some of those problems (like the
CFA_ULONG problem I had with containers) simply went away with later drops.
Others seem to still be here ... I wouldn't be at all surprised to find that
they are my problems, but the documentation is pretty skimpy, and the examples
too trivial (the one notebook example inserts one page of text and one page of
an icon, both of which are completely contained within the program).

I am using notebooks for setup, where I had been using dialogs whose
positioning and Z-ordering I managed within a setup window.  Last time I tried
them, they came up (looked real purty, too!), and I could move back and forth
among the pages at will.  Since I have a lot of pages (about 17 dialogs, as I
recall), it took too long to load; I found a way around that.  I also wanted
major tabs on all pages, but minor tabs on some; had to find a way around the
blank page that this requires (and I posted a request here a few weeks back,
that IBM alter the API so this workaround isn't necessary).


[More]

#: 75594 S14/Early Code
    06-Mar-92  19:52:32
Sb: #75593-Container Problems
Fm: Wayne Kovsky 76164,3504
To: Wayne Kovsky 76164,3504

[Continued]


All in all, notebooks look really good, not too difficult to use, etc.   BUT,
I have one major problem:  as soon as you hit a control in one of the dialogs
on one of these notebook pages, all behaves as it should (appropriate action
takes place according to what the control should do).  You can go to other
pages, and hit other controls, no problem.  As soon as you hit a second
control on a page that has already been hit, though, GP fault!  I am just
about to go back now to see if this remains a problem in this drop.  If it
still fails this way, I think I'm gonna need some help ... (the GP fault is in
the notebook's DLL, not in my code; I love these!).

By the way, these are the original dialogs, and they still work just fine in
the old method I used, so I am pretty sure the dialogs are not the problem; I
use the old stuffevery day to configure my program.  My guess is that this is
gonna be another head-slapper!

#: 75760 S14/Early Code
    07-Mar-92  09:44:44
Sb: #75374-Container Problems
Fm: Noel J. Bergman/DEVTECH 76704,34
To: Adam Goodman 100021,3161

Adam,

The product considerations says that the online docs describe GA, while the
headers describe current reality.

       --- Noel

#: 73431 S14/Early Code
    01-Mar-92  14:47:08
Sb: Sample Programs Bug Fix
Fm: Wayne Kovsky 76164,3504
To: Ian R. Ameline 70400,2356

Ian, there are some bugs in the 'style' demo program shipped with the 6.177
toolkit.  As shipped, the container demo shows nothing except a blank screen.
The reason is that a 'cb' field was added to some of the structures, and
'sty_dlg.c' does not initialize those new fields.

The first fix is applied just before original line number 1786 (or anywhere in
this vicinity):

  recordInsert.cb = sizeof(RECORDINSERT) ;           // Added line.
  recordInsert.pRecordOrder = (PRECORDCORE)CMA_END;  // Original line.

This fixes the container so that records show in the icon, name and text
views, but still not in the detail view.  To fix that, add this line at
original line 1819:

  fieldInfoInsert.cb = sizeof(FIELDINFOINSERT) ;     // Added line.
  fieldInfoInsert.pFieldInfoOrder = (PFIELDINFO)CMA_FIRST;  // Original.

Now, I hope you will read my message in this forum about problems with the
detail view of containers ...

#: 73432 S14/Early Code
    01-Mar-92  14:47:15
Sb: FIELDOFFSET Bug
Fm: Wayne Kovsky 76164,3504
To: Ian R. Ameline 70400,2356

Ian, in the 6.177 toolkit, the FIELDOFFSET macro is defined in three different
header files:  BASEMAC.H, OS2DEF.H, and OS2DEF16.H.  I think that the
definition in OS2DEF.H is incorrect:  it has the result cast to a SHORT (just
as OS2DEF16.h does, although that is probably correct for 16-bit headers,
unless it should be a USHORT); I believe the OS2DEF.H definition should be a
ULONG, as it is in BASEMAC.H.

I was looking closely at this macro, trying to figure out what is causing my
container details view to abort.  Unfortunately, this had nothing to do with
it ... I don't have any structures where offsets would exceed the capacity of
either a SHORT or a USHORT.  Just thought IBM should know.

#: 73434 S14/Early Code
    01-Mar-92  14:47:32
Sb: Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Ian R. Ameline 70400,2356

Ian, in addition to my problems displaying a container in details mode, I am
having a problem with sorting.  The CM_SORTRECORD message takes as one
parameter a PVOID that points to user storage.  I am trying to use that to
pass an allocated structure to the 'Compare ()' function (whose address is
passed as the other parameter of this message).  However, when I enter the
compare function, the PVOID that is the third parameter to that function is
not the address I expect (nor does it point to an address that I expect).

I have tried passing my address in different ways:  for example, as the actual
pointer to the structure, or as the address of a pointer to the structure.  Do
you have any idea how to use this field (or can you pass this message to
someone who works in this area)?

#: 79022 S14/Early Code
    15-Mar-92  18:03:07
Sb: Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, sorting is now working great here; thanks for the tip on the _System
designation of the comparison function.  Once I had that, sorting of dates,
times and ULONGs fell into place immediately; I had to do one more "rev" to
get strings right (I was missing one level of indirection).

Now if I could just find some magic wand to make container loading go a little
faster; even with only a (relative) handful of records (fewer than a hundred),
the time from "Go!" to first display is almost 25 seconds.  I think the
majority of this time is spent in loading an icon for each record (I'll
confirm with a test sometime soon), but that is something that my app calls
for, so I gotta do it.  I know about the 'delta' option of containers, but the
docs say this is for "thousands" of records, and that it isn't necessary for
smaller quantities of records.  I think I am going to have to use this option
anyway, and after getting a page, let a thread continue to fill the container,
then readjust the delta back to zero.

Just thinking out loud here ... let me know if you are NOT seeing long delays
on container fills.  I can read these same files and display them in my own
window in just a second or two, versus 25 seconds for containers; that kind of
delay just isn't gonna fly unless I can hide it in a background thread.

Thanks again!

#: 79083 S14/Early Code
    15-Mar-92  23:51:31
Sb: #79022-Container Sorting
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504 (X)

Wayne, good to see sorting is now working. Yeah, I am seeing long load times
also. It is especially noticeable to me because I am using a container as a
split-listbox so the performance hit versus just a regular listbox is pretty
bad. I think you'll also notice that scrolling in a details view both
vertically and horizontally is slow. Notice how slow the hilite bar is if you
hold the mouse down and drag it.

The good thing is that the performance has gotten better (details view) on
each release. I'm hoping they do some optimization come GA.

Rick

#: 79190 S14/Early Code
    16-Mar-92  08:22:27
Sb: #79083-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, as promised, I did a test to see how loading the icons affects the "fill
the container" times.  My test had three measurement points.  First, I
measured (a coarse measure:  I used a stopwatch on a system that was running
only my program) the time to load the container, with each record having a
unique icon that had to be loaded for it.  This is the way my app normally
works -- except that I "stacked the deck" in favor of performance just for
this test, by having every record load the SAME icon; this filters out the
file system from the equation.  I use 'WinLoadFileIcon ()'.

Next, I altered the program to use the program's icon for every record -that
is, I only had to set a pointer to the icon, rather than load a new icon, for
every record.  Finally, I measured the time it took to read and format the
same file, but to put each record into a standard window, one record per line.
The file contains 20,776 bytes (with a small header, probably less than 100
bytes), and something like 75 records.  Here are the results:

    Container load, 'WinLoadFileIcon ()' per record:  25.8 seconds
    Container load, program's icon per record:        12.2 seconds
    Window load, program's icon per record:            1.4 seconds

This is worse than I had expected, and needs some aggressive attention from
IBM.  The 32-bit PM stuff will help some, but I don't expect an order of
magnitude improvement from just that!  I imagine containers have a lot of
potential for tuning, given their newness to 2.0, so I'm not particularly
worried about it -- however, it does mean I am going to have to write a lot of
extra code so that I can "hide" this performance deficit from the user, until
it is fixed.  (And yes, I have noticed the slowness in scrolling as well -- it
looks like the work of a PM rookie.)  Since containers are at the heart of
WPS, I imagine this will get the attention it deserves, and quickly.

#: 79477 S14/Early Code
    16-Mar-92  21:06:14
Sb: #79190-Container Sorting
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, interesting numbers. It's starting to make me realize that I've got to
measure the performance of my details-view container after GA to determine if
it would be better to develop my own split-listbox rather than rely on the
container to deliver that functionality. It looks like your performance
measurement on using just one icon is equivalent to loading a details-view
container. 12.2 seconds for 75 records is pretty horrible - can't expect a
user to like that. It means that  multi-threading the loading of the container
would become a necessity - even for small amounts or records.

Here's hoping we get some serious performance dudes in on optimizing the
container code!

"WinLoadFileIcon" - good catch. Where'd you find it? It's not listed in the
online doc 'contents' window, but I can find the 'syntax' window on a search.
U been scanning the header files (I've got to do that when I've got the time)
or do you have the hardcopy docs?

BTW, just got the hardcopy programming guides ( not the hardcopy references ).
I'm VERY disappointed - they don't give much more info than we already know
and don't even address the tidbits we found out ourselves - they don't even go
into CM_SORTRECORD. I DID notice that deltas are not supported in the icon
view.

Rick

#: 79655 S14/Early Code
    17-Mar-92  08:31:48
Sb: #79477-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

On 'WinLoadFileIcon ()' -- I found it in the on-line docs, but not under
"Window Functions"; it is under "Workplace Functions".  You will find a few
other "interesting" functions in that section.

On my posted numbers, you should not look at them as absolutes (as in,
"sheesh, it takes 12.2 seconds to load 75 records"), but rather as
relationships ("sheesh, it takes 10 times longer to fill and display a
container than to fill and display a buffer").  I deliberately picked a test
that took an inordinately long time (because of a lot of extra processing that
is going on per record), in order to give me larger numbers whose ratios were
more obvious.  In other words, if I had a simple "read - move - post
CM_INSERTRECORD" loop with only 75 records, the times might have been quicker
than my stopwatch finger.  What is significant is that both the container
version and the non-container version go through identical code right up to
the CM_INSERTRECORD statement; then, the non-container version puts the
prepared record into a memory buffer from which the window proc will later
paint it onto the screen.

What is also significant is that the container version takes almost exactly
twice as long when you add exactly one statement:  'WinLoadFileIcon ()' (per
record), even when that statement goes after exactly the SAME icon each time
(which should largely negate file system impact, after the first icon is found
and loaded).  I differ with you slightly on your conclusion:  I conclude that
multi-threading absolutely IS a necessity for loading a container, even for as
few as 25 or so records.

How did you get the hardcopy programming guides?  I am a member of DAP, 32-bit
Expedite, and EADP -- is there somebody I have to BRIBE as well?

#: 80415 S14/Early Code
    18-Mar-92  21:26:44
Sb: #79655-Container Sorting
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, thanks for the tip on the progref Workplace functions. Maybe the reason
for the performance problem of the WinLoadFileIcon API is the number of steps
it takes to find the icon. The docs say that first it looks for an .ICON
extended attribute, then searches the exe's directory for a file with the same
prefix and a .ICO extension, then it looks in the EXE header. If your icon is
in the EXE header and your EXE were located in a directory with many files in
it (BIG assumption, I know <g>), the API would first search the EA's then do a
DosFindFirst, DosFindNext loop, then go to the EXE header. Also, if you don't
pass the fully qualified path of the EXE file, it would need to do a
DosSearchPath. Plenty of opportunity for time lag.

 >How did you get the hardcopy programming guides?  I am a member of DAP,
32-bit
 >Expedite, and EADP -- is there somebody I have to BRIBE as well?

These were announced along with all the beta drops. I ordered them during the
6.177 drop and paid I think $199 for the package that gives you the CUA
guides, Rexx users guide and PM, GPI, Control Program programming guides,
although I heard they've gotten considerably cheaper since then :(

You should be able to order them through the 800-426-3040 line. They are part
of the technical library and are 'pre-release' versions with no upgrade at GA.
You can probably get the production copies pretty soon. The hardcopy
programming references are also available - don't know how much they are tho.

#: 80544 S14/Early Code
    19-Mar-92  09:33:51
Sb: #80415-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

As it happens, Rick, the *.ico file I am loading is in the directory where I
keep my sources, makefiles, etc.  The number of files stored in that directory
varies hugely, depending on what I am working on at the time, but right this
minute has 161 files.  Next time I have some spare time (Ha!), I'll put the
*.ico file into its own directory and try my test again.  I don't really think
it will matter that much (the *.ico file has an EA, so it should be found
immediately), but you never know ...

Also, I hope they are not really doing a 'DosFindFirst ()/DosFindNext ()'
LOOP.  With OS/2 memory management, it would be better to NOT find a file at a
time, but rather to provide a buffer large enough to find them ALL in one
swell foop (I have run tests to confirm this hypothesis).

I didn't realize the hardcopy guides you were talking about were the $199 doc
set; I have that already.

#: 80894 S14/Early Code
    19-Mar-92  23:29:12
Sb: #80544-Container Sorting
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

 >Also, I hope they are not really doing a 'DosFindFirst ()/DosFindNext ()'
LOOP.  With
 >OS/2 memory management, it would be better to NOT find a file at a time, but
rather
 >to provide a buffer large enough to find them ALL in one swell foop (I have
run tests
 >to confirm this hypothesis).

Good point, Wayne. That should minimize the disk I/O.

 >I didn't realize the hardcopy guides you were talking about were the $199
doc set; I
 >have that already.

I heard that the price came down. I hope you didn't do the "I've got to have
them" like I did and pay the full $199. Although judging from one of your
messages that I read you're probably as bad as I am about wanting as much doc
as you can get <g>.

#: 79185 S14/Early Code
    16-Mar-92  08:21:20
Sb: #79022-Container Sorting
Fm: Lynn Teska 72361,1113
To: Wayne Kovsky 76164,3504

Are you at 6.177? 304 is MUCH faster here. Lynn

#: 79240 S14/Early Code
    16-Mar-92  10:40:28
Sb: #79185-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Lynn Teska 72361,1113

Yes, Lynn, I am on 6.304.  When you say 304 is "MUCH faster here", do you mean
that you have done similar tests, and the relative differences between them
are not as great as I reported?  If so, please post your results.  If you
haven't done such tests, then perhaps what you really mean is that your system
(which is different from mine) runs your apps (which are different from mine)
much faster than I report; I wouldn't be surprised.

The test results that I reported were not done in a sufficiently rigorous
manner that they should be taken as absolutes.  I did the timing with a
stopwatch (notoriously subject to error), and I was not careful with things
such as disk fragmentation between runs.  Nor did I post the contents of the
records that are being put into the container, nor did I describe the
processing that must be accomplished to convert disk-stored records into
displayable records suitable for a container.  All in all, if this were an
attempt at a repeatable, good-for-any-configuration benchmark, I would be
pretty ashamed of such sloppy work.

However ... for a moderately controlled, reasonable approximation of the
"cost" of filling a container with displayable records versus filling a window
with the same displayable records, and the additional "cost" of loading an
icon per record, I think my numbers will be repeatable in their ratios, and it
is those ratios (relative performance) that I was trying to show, and that are
the problem.  My results show about an order of magnitude cost to use a
container (versus fill a buffer and display it, and ignoring the cost of
loading icons).  If you have results that are, say, 50 percent better, I
wouldn't be surprised, since you are not running my tests on my hardware --
but that is still a pretty high performance cost.  If you have tests that seem
to show a negligible cost, please post them, and your methods for obtaining
them; your experience differs from ours.

#: 79639 S14/Early Code
    17-Mar-92  07:47:57
Sb: #79240-#Container Sorting
Fm: Lynn Teska 72361,1113
To: Wayne Kovsky 76164,3504 (X)

I mean to say that 304 is much faster than 177, thats all. Lynn

#: 79664 S14/Early Code
    17-Mar-92  08:59:39
Sb: #79639-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Lynn Teska 72361,1113

Lynn, there aren't that many folks around who seem to be using containers yet,
so please, give us more information about your experiences.

For example, in my testing, I am inserting all the container records in one
swell foop, rather than one at a time.  Are you doing it differently?  In
addition, I am using CMA_END to add records at the end of the record chain,
and I am using NULL as the parent record address.  Might it be faster to
specify a record address AND insert records one at a time?  (Depending on how
the container code is written, either of these methods could logically be
faster than the other.)

I did try some of these experiments, but not since 6.177, and not as carefully
as I could do now (I was still learning how to use containers at that point).
So far, it is only Rick and I discussing these issues; since you are using
containers, please joinin and give us the benefit of YOUR experience.

#: 80229 S14/Early Code
    18-Mar-92  15:57:39
Sb: #79664-Container Sorting
Fm: Lynn Teska 72361,1113
To: Wayne Kovsky 76164,3504 (X)

Wayne: Sorry you missed my point. I am not programming containers, since I
don't have the C/Set2. Still using M$ C6.  I, however am using 304 and the
containers that the system uses in 304 appear much faster than 177.  But,
obviously not fast enough, for you (or me) yet.  I will have to wait till
after GA to check out the containers, from the programing standpoint. Since
the EADP closed 3-1-92, and they didn't call me back. FWIW Lynn

#: 80273 S14/Early Code
    18-Mar-92  18:02:20
Sb: #80229-Container Sorting
Fm: Wayne Kovsky 76164,3504
To: Lynn Teska 72361,1113

Lynn, I would call again on the EADP.  I have reason to believe that it may
not really be "closed", although you are correct that the official closing
date has passed.  This is a really good deal, for $750 you get a paid-up
license to OS/2 2.0, C Set/2, WorkFrame/2, the programming toolkit (headers
and libraries and tools), Mirrors, Oasis, etc.  For the price of an 800-number
call <g>, it would be worth one more try.

I agree with you that containers are faster at 6.304 than at 6.177, but they
are still very slow (as you note).  I think that a speedup here will do more
for the enthusiasm people have for WPS than anything else (including making it
multi-threaded, although that is also a crucial need).

If you get the toolkit and do start getting into this stuff, jump right in;
there are a lot of pitfalls and some of us "scarred veterans" can steer you
around most of them now.

#: 73435 S14/Early Code
    01-Mar-92  14:47:43
Sb: Container Details View
Fm: Wayne Kovsky 76164,3504
To: Ian R. Ameline 70400,2356

Ian, after this message, I will leave you alone for awhile ...

I am having tremendous difficulty tracking down a bug in trying to display a
details view of my container.  I can show records in Icon, Name or Text views
with no problem.  However, as soon as I try to display in Details view, I get
the following error:

 General Protection Fault exception occurred at EIP = 197D5DC0 on thread 0001.
 Register Dump at point of exception:
 EAX = 00312020    EBX = 000000BA  ECX = 00000000    EDX = 00000006
 EBP = 00060001    EDI = 00060000  ESI = 00063C04    ESP = 00063BB4 CS =
005B  CSLIM = 1BFFFFFF   DS =     0053  DSLIM = 1BFFFFFF ES =     0053  ESLIM
= 1BFFFFFF   FS =     150B  FSLIM = 00000030 GS =     DFFC  GSLIM = 00000000
SS =     006B  SSLIM = 1BFFFFFF
 Process terminating.

This is in the container DLL, not in my code.  I have reached the limit of my
ability to debug this.  I have examined every related structure, both at the
source code level and with IPMD during execution, paying particular attention
to pointers, offsets, lengths and such.  My code looks very much like the
'style' sample code for containers, with one large exception:  I define the
fields one time, BEFORE I load the records; 'style' loads records, then
defines fields.  (My code will load different files at different times, and I
did not want to redefine fields each time.)

Can you (or someone) tell me what I should be looking at, based on this
termination message?  Help, please!

#: 73682 S14/Early Code
    02-Mar-92  09:38:41
Sb: #73435-Container Details View
Fm: Ian R. Ameline (IBM C) 70400,2356
To: Wayne Kovsky 76164,3504 (X)

Wayne,

   I'll forward your toolkit comments to the guy responsible for the
toolkit. FOr your PM/WPS problems, Steve (from PM development) can probably
help you much better than I can. I haven't yet had a chance to play with the
new control goodies on 2.0.

Regards,
Ian.

#: 73728 S14/Early Code
    02-Mar-92  10:53:54
Sb: #73682-Container Details View
Fm: Wayne Kovsky 76164,3504
To: Ian R. Ameline (IBM C) 70400,2356 (X)

OK, thanks, Ian.  Can you give me Steve's full name and CServe ID?  I recall
seeing him on here, but don't have that information.  What's in it for you?
You won't get eight messages from me tomorrow!

#: 74072 S14/Early Code
    03-Mar-92  01:53:57
Sb: #73728-#Container Details View
Fm: Alan DuBoff(Bunker Hill) 76662,660
To: Wayne Kovsky 76164,3504

Wayne,

In case it's a couple days before Ian gets back to you, her was refering to:
Steve Woodward 76525,1266.

ajd

#: 74163 S14/Early Code
    03-Mar-92  10:18:05
Sb: #74072-Container Details View
Fm: Alan DuBoff(Bunker Hill) 76662,660
To: Alan DuBoff(Bunker Hill) 76662,660

>In case it's a couple days before Ian gets back to you, her was refering
>to: Steve Woodward 76525,1266.

You idiot! You referred to Ian as *HER*, Ian is going to be mad at you
now...

ajd

#: 74276 S14/Early Code
    03-Mar-92  14:20:52
Sb: #74163-Container Details View
Fm: Ian R. Ameline (IBM C) 70400,2356
To: Alan DuBoff(Bunker Hill) 76662,660

>"Ian is going to be mad...."

   Ian has very thick skin. (But don't push me too far <g>)

#: 73447 S3/Ver. 1.x Developers
    01-Mar-92  15:01:45
Sb: #73412-Vanishing Controls
Fm: Wayne Kovsky 76164,3504
To: Dirk van Wie 100014,246

Dirk, it is probably way too late to suggest this, given the timeframes you
mentioned, but I will suggest it anyway:  your application sounds like it was
just made for containers.  You could show all the columns from which a user
might choose, and then as they selected columns that they do not want, you
could hide those columns (a simple message to the container control, after
setting the right structure).  All of the mucking about with showing or hiding
windows is handled by the container.  In addition, the container controlhas a
'delta' built into it, which anticipates and allows for use in a database.
Basically, you set the delta, and you get a message when the displayed records
are getting near the end of your data; at that point you load more.

Even if it is too late for tis project, I urge you to read the documentation
on containers very carefully for your next project.  This is probably the
slickest control in PM, and I think it hasn't attracted very much attention
yet.

Sorry I couldn't help on your current problem.

#: 73754 S3/Ver. 1.x Developers
    02-Mar-92  12:18:17
Sb: #73447-Vanishing Controls
Fm: Dirk van Wie 100014,246
To: Wayne Kovsky 76164,3504


Wayne,

thanks for the inspiration on containers.  Since I am one of the CLONE PEOPLE
left behind since 6.149 I haven't had a chance to experiment with containers
except at several demos. I would love to try this out.  Perhaps 304 will
finally install on my EISA 486; if not I will have to wait until Adaptec
releases workable drivers.  Where are containers documented ? Is that part of
SOM ?

#: 73901 S3/Ver. 1.x Developers
    02-Mar-92  18:11:33
Sb: #73754-Vanishing Controls
Fm: Wayne Kovsky 76164,3504
To: Dirk van Wie 100014,246

I think containers didn't come in until 6.167, but I don't recall for sure.
They are part of the standard Presentation Manager API, but they also figure
prominently in SOM.  They are documented on-line (somewhat incompletely and
somewhat inaccurately; you need to read the structure definitions in
'pmstddlg.h' to get the complete picture), and they are documented in "IBM
OS/2 2.0 Programming Guide Volume II, Presentation Manager Programming
Interface".  That manual may or may not be part of the standard 2.0 toolkit
documentation set -- I bought some extra manuals that were not part of that
set, and I don't know which are which.

In addition, in 'toolkit\c\samples\style' is a suite of C sources that
implement a (very elementary) container -- and that, with a couple of bugs
that make the container not show up at all.  I posted a note to Ian Ameline on
that subject, including the fix; it should still be here if you scan for it.

When you get 6.304, you will find that the WPS is itself a container, as are
all the folders.  The container allows different "views" of its contents, such
as Icon, Name (icon + text), Text, Tree and Detail.  In all of these views,
text that is part of the container display can be directly edited (providing
the progammer has allowed for handling the messages); the container can be
sorted or searched; records can be inserted/deleted; fields can be made
invisible or protected from editing; drag and drop can be supported (by
handling the messages); records can be selected by any of several methods
(marquee selection, swipe selection, etc.); multiple or single selection is
supported; I could go on and on.  Take a look when you get your kit installed
(and good luck!).

#: 74286 S3/Ver. 1.x Developers
    03-Mar-92  15:08:17
Sb: #73901-Vanishing Controls
Fm: Dirk van Wie 100014,246
To: Wayne Kovsky 76164,3504


Wayne,

I was notified that I will be sent all tools and OS/2 beta on a CD-ROM
diskette.  Which CD-ROM drive are you using ?

Thanks for the info on Containers.

Dirk

#: 80290 S14/Early Code
    18-Mar-92  18:32:33
Sb: Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

He's baaaaaaack!

Now that sorting containers is all sorted out, I have moved on to direct
editing, where there are yet more surprises.  In the hope that you have
already earned your scars in this area, I turn to you yet again for advice!

I get the CN_BEGINEDIT message, which is nearly useless; I simply set a flag
to remind me NOT to send the container any messages until we are done.  The
CN_REALLOCPSZ looks like it has the "meat" of this message sequence -- but, it
turns out that the 'ppszText' field of the CNREDITDATA structure points to the
ORIGINAL contents of the container record.  This message allows you to say
"yes" or "no" (via return code) to allowing the editing, but you don't yet
know whether the changed data meets all requirements for allowing it to
replace the existing data, because you haven't seen the new data yet.

OK, thinks I, I'll verify it on the CN_ENDEDIT message, and disallow the
change at that point if necessary.  This is not a wonderful idea, though,
since there is no way to return a "FOR GOD'S SAKE, DON'T DO IT!!!" return code
to this message; the fat lady has already sung.  You DO get to see the changed
data with this message, for all the good it does you.  I can think of ways to
"cheat" here, but I think I must be missing something that would allow me to
do it "The Cowboy Way" (I hope you are a Writers in the Sky fan, or that might
be pretty obscure).

So, the old forehead could use another good slap, Rick.  Tell me that you've
already crawled through this, and show me the error of my ways.  (By the way,
once you know what to look for, the on-line documentation says very clearly
what 'ppszText' points to at what point in time.  Look under 'CN_ENDEDIT',
then 'parameters', then 'CNREDITDATA', the 'ppszText', and there it is, bigger
than Dallas and twice as ugly.)

#: 80416 S14/Early Code
    18-Mar-92  21:26:58
Sb: #80290-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, sorry but I haven't yet coded for direct editing but I have thought
about it a lot. I thought it sounded great at first but then I thought of a
couple of issues and decided at first to make my text read-only until I came
up with solutions. As you pointed out, there is no built-in way to edit the
new text string before deciding whether or not to allow it (I don't think you
are missing anything - I THINK it's just not possible). I figured that during
the REALLOCPSZ notify message I'd get the window handle of the MLE by
enumerating the child windows of the container and finding one with the MLE
window class. Then I'd query the text and know what to return from the
REALLOCPSZ message. I know - kludgy.

But the main problem is that there doesn't seem to be a way to set the text
limit of the MLE unless it is already created by the time the BEGINEDIT notify
message is sent and I enumerate during that message.

You'd think that the window handle of the MLE would be in the CNREDITDATA
structure, wouldn't you?

Big issue: I am allocating the memory for my strings by using the
CM_ALLOCRECORD message with extra bytes for the strings. This allows me to use
the CM_REMOVERECORD with the CMA_FREE flag with a 0 for number of records and
in one shot all records are removed and all memory freed so I don't need any
application heap maintenance for the container items. Only problem with this
is there is no CM_REALLOCRECORD message, so with direct editing I'd have to
come up with a way around this (something like REMOVERECORD, FREERECORD,
ALLOCRECORD, INSERTRECORD when the size of the string changed).

Boy, we REALLY need a 2.0 programming section, don't we?

#: 80547 S14/Early Code
    19-Mar-92  09:34:00
Sb: #80416-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Sheesh, Rick, I wish you were just down the hall or something; I think you and
I could have some great conversations.

Here's another tip for when you DO get around to direct editing:  the
CN_REALLOCPSZ message passes the size of the field needed to contain the NEW
data (while returning a pointer to the OLD data ... go figure); this is the
'cbText' field of the CNREDITDATA structure).

However, that size is NOT the size you would get from 'strlen ()' as you would
expect (or at least, as I did expect).  It seems to include the string
terminator.  Thus, if someone is changing an 'A' to an 'AB', the length passed
to you by CN_REALLOCPSZ is 3; I expected 2.

Getting the handle to the MLE:  that should work.  Another way to "cheat" is
to change the data in the container's copy of the record, during or after the
CN_ENDEDIT message (I haven't tried it yet; if it doesn't work DURING the
message, I will just post a WM_USER message to myself and do it later). The
problem is that none of this should be necessary ... we need a little more
functionality in the API.

#: 80895 S14/Early Code
    19-Mar-92  23:29:18
Sb: #80547-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, agreed about needing more functionality in the API. There are
definitely some rough edges. Boy, I wish I had more time to work on my 2.0
stuff. I have a contract doing a 1.3 app and that is taking most of my time.
I'd really like to start digging into my 2.0 code so I could complete the
container functionality, add the notebook, etc. You sound like you're REALLY
making progress. A little battle-weary maybe, but I bet you're loving it<g>!

#: 81026 S14/Early Code
    20-Mar-92  11:09:40
Sb: #80895-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

"... but I bet you're loving it<g>!"

Yeah ... 'cause it feels so good when I stop!

#: 81227 S14/Early Code
    20-Mar-92  20:48:24
Sb: #81026-#Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504 (X)

Wayne, FYI, in case you haven't found it - I just noticed CID_MLE in
pmstddlg.h that can be used during any of the Direct Editing messages. At
least it makes it easy to get the hwnd of the MLE using WinWindowFromID. That
should make it possible to set the text limit of the MLE and query its text.
Will try this later.

The zombie message you mentioned - probably some real pearl of wisdom. If only
I could remember what it was...<g>.

#: 81255 S14/Early Code
    20-Mar-92  22:11:09
Sb: #81227-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

I almost responded to your earlier message about needing the handle of the
MLE, to tell you how to get it.  I had seen it somewhere, but when I went to
look for it, I couldn't find it -- but I only looked in the online docs, not
the header files.

When I get a new version of OS/2, I always print the headers, and spend a day
or so just reading them carefully (concentrating on any new ones).  I nearly
always find some real gems this way (this has been true all the way back to
1.1).  Anyway, that process is probably where I ran across this, but then I
couldn't remember it later -- brain cell entropy seems to be moving along in
double-time these days.  Thanks for the pointer.

#: 81623 S14/Early Code
    21-Mar-92  22:20:19
Sb: #80895-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, I have just re-run the tests I did, from which I concluded that
container record insertion is slow; it isn't!

These tests are not comparable, because since the last time I ran them, almost
everything on my system has changed.  I had to install 1.3 EE, which required
me to make room for a new partition, etc.  The net of it is that I have
re-installed 6.304, plus installing 1.3 EE; I have moved my swap partition
from an HPFS partition with about 25 MB free, to a FAT partition with about 8
MB free; and I have done a lot of work (mostly adding new code) in the
containers area of my code.  All these caveats aside, here come the results:

Same number of records (fewer than 100), and records themselves have not
changed (in content, nor in requirements for formatting for display).  Where
before I could only load these in about 12.5 seconds when I did not load a
unique icon per record, I can now do it in 1.2 seconds; and where before
loading a unique icon per record required about 25 seconds, it now takes just
over 6 seconds.

Why the huge discrepancy?  You've got me.  If anything, I expected all my
system changes to make things worse, not better.  This is really snappy
performance now -- the container almost pops up, where before it seemed to
take forever.  The earlier results were repeatable; I did them several times,
over a period of days, often after a fresh reboot, because they were so bad I
didn't quite believe them.  These new results are equally repeatable.

I'm going to leave cookies and a Jolt cola for the Intel god tonight.

#: 82137 S14/Early Code
    22-Mar-92  21:11:30
Sb: #81623-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wow! Those times are MUCH better than I'm getting. Is a sort going on during
those measurements?

#: 82277 S14/Early Code
    23-Mar-92  08:12:39
Sb: #82137-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

No, no sorting, Rick.  I store the file in the order last specified by the
user (who can request a sort while viewing the file, and can then save). When
loading, it is simply read/format/insert.  The 'format' step can be more
complex than it sounds, which is data-dependant; however, that did not change
between the old and new tests.

This is getting stranger, though.  That under-two-seconds time was highly
repeatable, both immediately after booting and after having run the system
hard all day long -- emphasis on the "was".  Now it is up to the 5-6 second
range -- still much better than my original times, but why should it be
deteriorating?  The new times are also highly repeatable, within a couple of
tenths of a second (remember, I am timing with just a stopwatch; it would be
more accurate to use the ANSI 'clock ()' function or something like that).

My code is changing quite a lot on an hour-by-hour basis, as I add new
features or fix bugs; however, I am not working in the container loading area
(and only occasionally in the container area at all).  It is possible that my
re-linking is moving something around, and the result is the slowdown -- but
remember that this is a 32-bit app (single data segment, single code segment),
so that seems unlikely.  Weird!

#: 82197 S14/Early Code
    23-Mar-92  00:02:02
Sb: #81623-Container Editing
Fm: Frank Mena 73507,3610
To: Wayne Kovsky 76164,3504

Wayne, sorry to butt-in,

Before you re-loaded 6.304, did you have alot of objects on the desktop and in
folders?  Did you run the new test without creating all these objects?  I
noticed that since I created and deleted alot of objects, opening folders (and
loading their icons) is alot slower.  If so, I think it might have something
to do with having a fresh os2.ini file, although I dont know if the OS2.ini
file has anything to do with this.

#: 82278 S14/Early Code
    23-Mar-92  08:12:46
Sb: #82197-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Frank Mena 73507,3610

You're not butting in at all, Frank; glad to have you.

I never did have what I would call "a lot" of objects on the desktop, or in
folders.  I am doing 99% development with this machine, so I have few apps
loaded on it (I have another machine for stuff like word processing,
spreadsheets, mail lists, etc.).  I had/have on the desktop just the standard
OS/2 stuff and the stuff that is put there by the toolkit installation (all
the docs, mostly).  When I re-installed 6.304, I had moved everything around
to make space for 1.3 EE, so before I did anything else, I also re-installed
the toolkit.

So, to answer your question:  the first time I did the timing tests after this
re-installation, the desktop looked pretty much like it had before the
re-installation.  One thing IS different:  the icons before were arranged
around the top, left and bottom, leaving the middle and right open.  This time
around they are arranged across the top only.  I'm not sure why, but I think
that when I did my first "arrange" on the old installation, I may have had the
center filled with a large window or two, and this time around I may have done
the arrange when only the icons were showing.  Otherwise, I think the desktop
is comparable to the earlier one, in quantity at least.

#: 82357 S14/Early Code
    23-Mar-92  12:51:34
Sb: #82278-#Container Editing
Fm: Frank Mena 73507,3610
To: Wayne Kovsky 76164,3504 (X)

Wayne, I have been following your thread about containers and notebooks for a
while.  I had started to work with them about 6 weeks back but had to pull
myself off to work on something else for a while.  Now i'm back.  You 2 guys
are worth more than the so-call  programmers guides.  Have you thought about
writing up what you have learned and upload it?  It would be invaluable
information to me and others, instead of me having to go back and try to piece
together your messages.

Thanks,

                Frank Mena

#: 82424 S14/Early Code
    23-Mar-92  16:16:55
Sb: #82357-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Frank Mena 73507,3610

Thanks for the compliment, Frank; maybe it will help to stop the bleeding! I
wouldn't mind writing up what I have learned (it is considerably more than we
have discussed here, which has concentrated on what I HAVEN'T learned!), but I
would need (A) time and -- most important -- (B) economic incentive. It isn't
that I'm mercenary -- just average in that respect, I would say -but I am busy
building a product while living on savings, so I have to be VERY careful how I
spend my time.

I guess I'll have to wait for one of the deep-pockets magazines to notice this
thread, and offer me Wealth Beyond My Wildest Dreams if I will only do an
article for them <g>.  And why not?  Ed McMann offers me that annually, and he
doesn't even expect me to write an article for him.

I had an article tentatively accepted by Byte, way back in early 1990 I think
it was, on techniques for debugging multi-threaded PM apps, but about that
time they decided to shift their focus away from OS/2, so the time I spent
writing that article was wasted.  Sure wish I had that time back! (Or a copy
of Byte with my article in it, to show my grandkids someday.)

Anyway, if you have any questions, jump right in.  I don't think there are
that many people in the entire metropolitan Universe who are using notebooks
and/or containers yet, so this may be The Place To Get Help for now.  I just
hope you aren't a competitor!

#: 82513 S14/Early Code
    23-Mar-92  18:47:07
Sb: #82424-Container Editing
Fm: Frank Mena 73507,3610
To: Wayne Kovsky 76164,3504

>I just hope you aren't a competitor!

I don't know.  You haven't told me what you're working on! <g>

#: 82587 S14/Early Code
    23-Mar-92  20:10:08
Sb: #82513-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Frank Mena 73507,3610 (X)

Nope, I haven't!

#: 81624 S14/Early Code
    21-Mar-92  22:20:27
Sb: #80895-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, a new problem:  container resizing.  My container is a window that
occupies the entire client window space when it is created.  When my client
gets a WM_SIZE message, I do a 'WinSetWindowPos ()', using the conhis code is similar to sample code for an MLE control; I
think that code is in the 'style' sample.

t is not. I
have noticed that I always have a horizontal scrollbar in the container for
all views, but I never have a verticthings got worse (things that were working as above, no longer
worked).  I didn't try sending it, in the belief that the client window was
not yet resized and it might fail for that reason (or be clipped to the old
client size).  I also tried posting a WM_USER message to the clienks for nice quick explaining. So subsystem / DLL is only a
difference how we can handle our C Set/2 DLL implementations. If we build only
DLL's for use / call with C Set/2 programs then i don't have to look at
subsystems. Ciao, Bernd

#: 82138 S14/Early Code
    22-Mar-92  21:11:43
Sb: #81624-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, try using SWP_MOVE on the WinSetWindowPos call. It sounds like you need
to reset the origin of the container to 0,0.

One thing I've done in the past with listboxes when I wanted it to be the
whole client area is to not create a client window, make the frame window the
parent of the listbox and specify FID_CLIENT as the ID of the listbox on the
WinCreateWindow call for the listbox. Also on the WinCreateWindow call specify
0,0 for the origin of the listbox and 0,0 for cx,cy. The sizing is
automatically done for you - no reason to intercept WM_SIZE. You have to make
the frame window the owner too and subclass the frame to get the WM_CONTROL
messages tho. I haven't tried that for a container yet but see no reason why
it won't work.

BTW, I bowed down to you yesterday. I started my notebook control coding and
spent 4 hours trying to figure out why the BKM_SETDIMENSIONS message did not
work for sizing the major tabs. After tearing my hair out (a couple of times),
I STARED at the WinSendMsg call. Then I said to myself, "What would Wayne, god
of the NOTEBOOK control, do in a situation like this?". And I remembered your
message (I **THINK** it was your message) about the docs saying to use
BKA_MAJOR but really having to use BKA_MAJORTAB. That was it! I couldn't
believe how a simple documentation error caused me so much grief. I also saved
myself a lot of trouble by looking over your message about not making the
notebook control the owner of the pages. Thanks. You can bet a lot of other
people are going to hit these nasties.

#: 82279 S14/Early Code
    23-Mar-92  08:12:53
Sb: #82138-#Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Thanks for the thoughts on my sizing bug.  I had used 'SWP_MOVE' at one time,
because I copied some code that I had used on 1.3, but I dropped it off
somewhere along the way when it didn't work.  I just read some messages from
someone at IBM (Sam Emrick, maybe?), acknowledging that some of the 'SWP_xxx'
parameters don't work, so I think this may be it.  Another thing I do is to
save my window(s)' positions on request, and next time restart them in the
same location/size.  That doesn't work on 6.304, but worked earlier (and I
haven't touched this code), so I suspect this may be the problem.

I have done almost exactly the same as you on listboxes, and have some of that
code around; I may try it.

Aren't notebooks fun?  Yes, that BKA_MAJOR instead of BKA_MAJORTAB cost me a
few hours, too!  I finally found it by poring over the header files, and
wondering why too such similar names were there.  This one goes back to at
least 6.177, and I think it was in 6.149; I don't know what is taking them so
long to fix it, but I presume most people will never hit it -- only us
pioneers!

If you have any pages that have both major and minor tabs, you will find an
API deficiency that results in a blank page when you select the major tab. If
you can't figure out a way around it, drop me a line; I solved that one a long
time ago.  Also, defer loading your dialogs -- saves a LOT of time in showing
the first notebook page -- do the load on BKN_PAGESELECTED messages. Come to
think of it, there are really quite a few "tricks" to using these things well
-- wanna see all the arrows in my back?

#: 82288 S14/Early Code
    23-Mar-92  08:34:51
Sb: #82279-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, I just tried the circumstances that you gave for the Container sizing
problem and got the same results as you. When I used SWP_MOVE with an x,y of
0,0, the problem went away and everything worked fine. You may want to try it
again.

Good luck,

Rick

#: 82415 S14/Early Code
    23-Mar-92  15:48:28
Sb: #82138-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Rick, I have now tried resizing my container window with SWP_SIZE, and it
works as expected.  I must have had something else wrong when I removed
SWP_SIZE, and I just never put it back.

I just tried my "save window position for next session" code again, though,
and it still doesn't work.  Same code still works on 1.3 (same logic, anyway;
the code itself is now 32-bit), and it worked on versions of 2.0 prior to
6.304.  I'm going to just leave it alone until I get the GA copy of the tools,
since someone from IBM said here that some of these positioning flags don't
work on 6.304.

Thanks for the help!

#: 82614 S14/Early Code
    23-Mar-92  21:05:36
Sb: #82415-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Wayne, glad to see you got it working. Another hash mark.

#: 80548 S14/Early Code
    19-Mar-92  09:34:06
Sb: #80416-Container Editing
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750

Also, I am handling the string allocation pretty much the same way you are.
However, I am being lazy (remember, I have fewer than 100 records, and that
will be typical for this particular app), by simply allocating each string
type to the maximum size for all strings of that type (like, name type,
address type, etc.).  That way, if a displayed string size changes, I don't
need to reallocate.

I wouldn't do this for a large database with thousands of records ... well,
come to think of it, I might.  By setting the delta to only a hundred or so,
there still is negligible memory waste, and diminished opportunity to fragment
memory.  It simplifies coding as well, but that isn't a criterion I like to
use in making tradeoffs of this sort.

Anyway, the REMOVE/FREE/ALLOC/INSERT is code that I already have, for things
like cut and paste, copy, delete, and add, so doing these operations because a
string size changed would be trivial.

#: 80896 S14/Early Code
    19-Mar-92  23:29:21
Sb: #80548-Container Editing
Fm: Rick Fishman 72251,750
To: Wayne Kovsky 76164,3504

Yeah, the delta is something I'm going to have to start doing. That seems like
the way to go. Always wanted that built into the listbox control in 1.x.

#: 80310 S4/Version 2.x
    18-Mar-92  18:55:19
Sb: #79658-Multicolumn list box
Fm: Peter G. Magid, IBM 70441,1634
To: Dave Proffer 70337,2544

Just want to confirm that we do use the standard
container control.

There are both PM Win calls and work place methods
for displaying information in that view.

- Peter

#: 80410 S4/Version 2.x
    18-Mar-92  21:08:10
Sb: #80310-Multicolumn list box
Fm: Wayne Kovsky 76164,3504
To: Peter G. Magid, IBM 70441,1634

Peter, I just noticed a peculiar behavior in the details view of a container
in my own program -- it could be my bug, but I don't see what I might be doing
wrong; I think it is in the container code.

In details view, and with a vertical separator, I put the mouse cursor over a
field in the right side of the split container, and hit Alt and LMB at the
same time.  The FIRST time I do this, the record that that field belongs to
has its NAME field briefly selected for editing (that is, the box is drawn
around it), then un-selected.  I do NOT get a CN_BEGINEDIT or CN_ENDEDIT
message for this field.  After this field is unselected, I must select again
the field I wanted; this time (and all subsequent times) it works.

This narrative is hard even for me to follow; here's a diagram:

   ID     NAME     |   ADDRESS      CITY      STATE
   1      Jones    |   Oak St.      New York  NY

"Jones" is the pszIcon string, the pszName string, and the pszText string, and
the container is "split" after the NAME field.  If I try to direct-edit "Oak
St.", it tries to edit "Jones" (but I get no messages from the container, and
the selection simply goes away after a few seconds).

I would try this on a details view of a system-supplied container, but I can't
find one that is split.  My bug, or the container's?

#: 80412 S4/Version 2.x
    18-Mar-92  21:08:19
Sb: #80310-Multicolumn list box
Fm: Wayne Kovsky 76164,3504
To: Peter G. Magid, IBM 70441,1634

Peter, I would appreciate it if you could have a look at message number 80290
in section 14 (Early Code), where I have a question about direct editing in a
container.

#: 81134 S4/Version 2.x
    20-Mar-92  17:06:32
Sb: %80544- Container Sortin
Fm: Wayne Kovsky 76164,3504
To: Rick Fishman 72251,750 (X)

Rick, I have a message from you, number 80894, when I scan for messages, but I
don't actually get the message; a zombie message!  It is shown as part of the
80544 Container Sorting thread in this section.

Anyway, if you (unlike me) actually said something noteworthy, you'll need to
re-send it; CompuServe is playing "keepaway" with me.

#: 81430 S4/Version 2.x
    21-Mar-92  11:32:49
Sb: #81134-%80544- Container Sortin
Fm: Larry Finkelstein[Sysop] 76702,1354
To: Wayne Kovsky 76164,3504

Wayne,

You should be able to retrieve that message, however it may be lower than your
high-message number, which is why you want find it you're reading new
messages.  However, a REA WAI or a REA NUM: 80544 command should get it for
you.

LBF

#: 81482 S4/Version 2.x
    21-Mar-92  14:09:39
Sb: #81430-%80544- Container Sortin
Fm: Wayne Kovsky 76164,3504
To: Larry Finkelstein[Sysop] 76702,1354 (X)

Yes, Larry, I have retrieved it now, by using 'Esc' to have TAPCIS leave me
connected.  I don't understand why (in several different sessions) TAPCIS
showed me that this message was waiting for me, but never retrieved it.  I
wonder if I am missing other messages that were NOT addressed to me (I would
never have known about this message had it not been addressed to me).

Anyway, I have retrieved it now; thanks.

#: 82032 S4/Version 2.x
    22-Mar-92  17:40:12
Sb: #81928-Notebook Control
Fm: David B. Lection [IBM] 74017,337
To: Matthew Woolf 100021,3546

Matt,

There is a set of manuals that are called the OS/2 technical compendium that
contains some documentation on the new controls. I will be out of town till
this Friday, but I can look into what it might take to get you a copy. Is
Friday OK?

Regards, David