dixon@sagittarius.crd.ge.com (walt dixon) (03/17/90)
I've just begun to use the windows sdk to develop code for windows/386
and have been wondering about a couple of things. The answers to these
questions may be burried in one of the manuals, but I have not stumbled
upon the answers yet.
(1) After I start up windows/386, I run command.com. When I try to make
an application, I usually get a msc (5.1) error saying that the far
heap is exhausted. Is this normal or do I have something improperly
configured? I'm running on a compaq 386 with 6MB. I've got reasonable
values for files and buffers in config.sys. lastdrive=v (I sometimes
run pc/nfs, but none of that software is loaded when I have this
problem). I've got ansi.sys and smartdriv.sys in config.sys, and
the microsoft mouse software is installed in autoexec.bat. There
are no other drivers or tsr's.
(2) Is there a preferred way to build the resource (.rc) file? All the
examples I've seen manually build dialogs, etc. and include their
definition directly in the .rc file. I want to use the available
utilities (dialog editor, etc). It does not seem practical to manaully
merge resource definitions into a .rc file, because it becomes cumbersome
to modify these resources. I'm currently using the rcinclude directive.
This approach works, but the resource compiler seems to be very picky
over include files. I've had to play with what appeared to be a valid
.rc file to get it to compile succesfully. Is there a better way?
I'm working on what will be a fairly large program.
(3) Is there an alternative to the icon editor? I'm not real impressed
with the way a 64x64 bit may gets shrunk to 64X32. The bits are too
small and the pencil cursor is too big.
(4) Is there a way to ask the dialog editor to ignore duplicate ids whose
value is -1? I thought a -1 meant that one did not care about the
id.
Thanks for your time
Walt Dixon {arpa: dixon@crd.ge.com }
{us mail: ge crd }
{ po box 8 }
{ schenectady, ny 12301 }
{phone: 518-387-5798 }
Walt Dixon dixon@crd.ge.combcw@rti.rti.org (Bruce Wright) (03/21/90)
In article <6132@crdgw1.crd.ge.com>, dixon@sagittarius.crd.ge.com (walt dixon) writes: > (1) After I start up windows/386, I run command.com. When I try to make > an application, I usually get a msc (5.1) error saying that the far > heap is exhausted. Is this normal or do I have something improperly > configured? You will need to modify the WIN.INI file entry for MSC or your PIF file for the compiler (wherever you declared the compiler) to give it more memory. > (2) Is there a preferred way to build the resource (.rc) file? All the > examples I've seen manually build dialogs, etc. and include their > definition directly in the .rc file. I want to use the available > utilities (dialog editor, etc). *gack* >choke< The dialog editor is a good idea, it is pretty easy to create dialog boxes with it. But its .rc output is nearly unuseable (as you are finding out). I usually build the dialog boxes manually with a text editor; it is more trouble than using the dialog editor but not that bad once you've done it a few times (and have a number of dialog boxes to use as starting points). I believe there are numerous commercial products out there that provide better solutions than you get with the SDK, but I don't have any experience with them so I can't recommend any. > (3) Is there an alternative to the icon editor? I'm not real impressed > with the way a 64x64 bit may gets shrunk to 64X32. The bits are too > small and the pencil cursor is too big. (you seem to be finding all the weak points in the SDK!). Using the icon editor to create a lot of bitmaps is a recipe for going blind. It's not too bad if you are only making one or two (though even then it's rather painful). You can use the Clipboard to move images between Paint and the icon editor; Paint is a >much< nicer bitmap editor than the icon editor, you just don't get to see the compressed icon as you are editing; but I find it isn't too bad, and you can easily move bitmaps back into the icon editor to see how they'll get compressed. The major drawback is that it is awkward to create 3- or 4- color icon bitmaps from Paint, but relatively few icons have many colors. As for the bitmap getting shrunk, as far as I know all display drivers shrink the icon bitmaps, though possibly a few high-resolution displays (such as the 8514) don't do so. There's no way to stop it. If you are talking about how non-icon bitmaps get shrunk with the StretchBlt function, there are some modifications you can make to the algorithm by calling the SetStretchBltMode function; but if you aren't happy with any of the possibilities that function allows then you will have to write your own. For what it's worth, the rumor mill has it that the SDK for Windows V3.0 solves many of these problems. No, I haven't seen it, and have no firm info. Good luck - Bruce C. Wright