#Bitmaps
34 messages in this thread
Hi George,
The real person who discovered it was Loren. Now that I have taken over
Compuserve for him at MS, *he* has the time to play to do all these niffty
things. …I wrote it though<g>! Glad you liked it.
Don Funk
There are 2 Replies.
Don,
Where is this file? Is it in the KB already or the SL? -=- Jonathan
Don,
Well, it took me a little time to figure out exactly how to use those GDI
calls, but it turns out that there's a helluva lot you can do with the
StretchBlt call. A little experimenting led to a lot of discoveries.
It would be terrific if this could be added internally to the next version
of VB.
I know I've said this before, but I really believe that the average user of
VB doesn't want to have to use API or GDI calls. It's not easy, as you
know. The more that's put in the program itself, the better a job the
average user can do.
Off my soap box,
George
P.S. Thanks again.
There are 2 Replies.
Hi Goerge,
I agree that the average VB programmer doesn't want to make api
calls…although I enjoy trying to figure them all out.<g> I will add this
to the list.
If this was added to the next product, wouldn't it really be the same
call that you are making now?…with the same arguments? The only
difference I see is that you would have a reference to the call
in the runtime(ie. larger BRUN100.DLL) whether you make the call or
not and you wouln't have to add a "Declare" statement in the global
declaration. Does this really add advantages to including it into
the next release? ie. larger runtime?
Don FUnk
There are 3 Replies.
Don,
If I might express my vote. I think it would be *much* more
important to add support for the features left out of VB that *cannot* be
accomplished with simple DLL calls. There are a lot of "events" that
aren't covered by VB and there are a lot of API functions that require
callbacks, many of which are covered but some are not. I think you should
concentrate on adding stuff that we can't. Just my humble opinion. -=-
Jonathan
There is 1 Reply.
Hi Jonathan,
I feel you have a good point there about adding features the you "can't"
do in VB such as call-back functions. Very good point. Could you let me
know what functions other that the printer-dll that you would like to use?
Don Funk
There are 2 Replies.
Don,
Other callbacks? How about all the Enum stuff? And I'm assuming that for
VB to support callbacks, we're gonna have some sort of MakeProcInstance?
That would certainly be useful!
– Ted
There are 2 Replies.
Ted,
Don't look for MakeProcInstance to soon from a p-code engine!<g>
However, it *does* seem like it should be possible to create a generic
call-back function that triggered an event. You sould then read the stack
manually or maybe it would have to be passed to you as a string…Hmmm.
-=Jonathan
There is 1 Reply.
Jonathan,
>Don't look for MakeProcInstance .. from a p-code engine
I wasn't. I'm hoping that there'll be a native-code compiler and then this
wouldn't be a problem. However, a generic call-back function would be an
interesting substitute.
– Ted
There is 1 Reply.
Ted,
It is my *opinion* that since they are building embedded BASIC, it
is unlikely that they will move to a native code compiler. In fact, it is
further my opinion that there are many more important things to be doing
other than that. They could be working on a debugger, speeding things up
so that it is as fast as embedded C and essentially building more
functionality into the language. Since the language engine will soon be a
part of Windows, the overhead to the programmer and user would be minimal
and the possibilities are endless. One nice feature will be support for
embedded BASIC from *within* VB apps.
Given the current trends in hardware and software, I think a native
code compiler is is a low priority. Just my opinion. One caveat, of
course, is that it is essential that we get a way to write DLLs in BASIC
but it seems to me that this could be another, lower level, product. What
things thou? -=- Jonathan
There is 1 Reply.
Jonathan,
I definitely agree that debugging features (I'm barely able to call what VB
has now as being debugging features), along with things like form arrays
are definitely more important than a native-code compiler. And yes, since
something akin to the VBRUN100.DLL will eventually be built-in to the
Windows package, the overhead isn't a big deal (it never was a big deal for
me). Speed is certainly a factor (yes, hardware is getting faster, but I
can't simply forget about all those people with 286s or 386sxes), but I
really want to be able to code DLLs and Custom Controls in Basic, so if
it's not VB, but QB5.0, then that will make me happy. But then things like
a generic callback would definitely be needed, along with some built-in
pointer support for easier memory allocation and access (although things
like >64K arrays and REDIM PRESERVE would make those needs go away quite a
bit, and I'm sure it'll appear before pointer support).
– Ted
There are 2 Replies.
Ted,
Did you see my VBPOINT.DLL? It has a memory copying routine in it
which is all that is required for VB programmers to deal with pointers.
It's one of those 101 uses kinds of things. Check it out.
As for speed, I am sure that it will improve with Embedded BASIC. I
think actually that DLL and control construction belongs outside of VB
anyway and it will get supplied, either by MS or by Crescent. -=- Jonathan
There is 1 Reply.
Ted (and Jonathan/others)
I strongly agree with you. In particular I'd like to see the ability to do
DLL's with BASIC including the ability to pass *Basic* strings (dynamic)
*and* arrays of them in the parameter list.
I take a little stronger opinion on native code. I think its a must.
Hopefully MS is working on providing us the ability to create native code
DLL's that accept all Basic data types.
Dan <dreamer>
Hi Ted,
I will add the the desire for some "call back" ability to the "wish
list". Thanks,
Don Funk
There is 1 Reply.
A native-code generator would be nice…or perhaps a Visual Basic-to-QuickC
for Windows source code conversion utility…(g)
Don,
Well, I would have to sit down and figure this out but off hand: All
the relevant messages that get sent to the various controls should be
included as events. WM_MOUSEACTIVATE is a *big* one for a lot of people.
There are other messages that I am sure people would like to hear about.
As for callbacks, how about support for HOOKs and sub-classing? Even this
stuff can be fudged with the CDK but not too many people are masters of
that…even the masters!<g> My *most* important recommendation is form
instancing (form arrays or something similar). This is something that
simply *cannot* be done by a third party and has to be done by you. In a
resource driven environment such as this, it should be easy to add this
functionality. That's the feature I personally want most and if you added
it, I would even be willing to donate the rest! -=- Jonathan
There is 1 Reply.
Don,
I know with all the hanging out I do here this is going to sound
silly but, Where is the information on the VB API calls? Like how you do it
and what they are?
Charlie
There is 1 Reply.
Hi Charles,
Hope this helps,
Don Funk
1. "Microsoft Windows Programmer's Reference" book and Online Resource
This complete reference to the Microsoft Windows API includes the
following:
a. A comprehensive 1152-page reference book for Windows 3.0
(published by Microsoft Press, 1990)
b. Online references to each component of the Windows API in
Windows Help format. Includes both 5.25-inch and 3.5-inch disks.
c. WINAPI.TXT: Function, Type, and Constant declarations in Visual
Basic format for nearly every Windows API function. Note: A
correction for the WINAPI.TXT file dated 5/14/91 is described in
a separate article in this knowledge base. To find that article,
query on the following words: WINAPI.TXT and correction.
d. APIXREF.HLP: Quick reference listing the value of every constant
and the appropriate library for every function.
Kit number: 1-55615-413-5
Price: $49.95 (plus shipping/and handling and applicable sales tax)
There is 1 Reply.
Don,
As I already have the programmers reference I don't need another
copy <g>. But you say WINAPI.TXT is aval. it the KB? If so I'll go get it!
(or is it avail in a lib here?). I guess the On–line help stuff is in the
VB help file?
Thanks Charlie
If there were a VB available on other platforms, such as the Mac, I would
make the argument that the more we have to rely on the API and third-party
add-ins, the less portable the software is, but since there is no VB
available on the Mac…
(Only youse guys know if this is likely to be a problem in the near future
or not.) <g>
Hi Goerge,
I agree that the average VB programmer doesn't want to make api
calls…although I enjoy trying to figure them all out.<g> I will add this
to the list.
If this was added to the next product, wouldn't it really be the same
call that you are making now?…with the same arguments? The only
difference I see is that you would have a reference to the call
in the runtime(ie. larger BRUN100.DLL) whether you make the call or
not and you wouln't have to add a "Declare" statement in the global
declaration. Does this really add advantages to including it into
the next release? ie. larger runtime?
Don FUnk
There are 2 Replies.
Don,
IMHO, I think items like this (printing and scaling graphics) should
definitely be included as internal VB commands, bigger VBRUN
notwithstanding.
While you're absolutely correct that it will still require similar
variables, the user won't be forced to figure out the arcane way that API
declarations and calls are done.
Instead of the strange stuff we now have to do to deal with StretchBlt, the
user could simply write to properties like ScaleX, ScaleY, PrintBitMap,
etc.
Remember, if you will, that not everyone is able, or even willing, to
extend their knowledge to do stuff.
Yes, this is version 1.0, but…I think that the capability to put a
graphic on the screen in a number of ways should be extended to printing
that same graphic, whether or not you want to print text on the same page.
What is the user going to want to do? That seems to me to be the question
for software designers. It's easy for someone who is comfortable with the
SDK to say, "Well, they can make a call to an API function to do that…"
Still, I wonder just how many people are capable of figuring out the stuff
you must do to scale graphics and print them *with text* on the page.
I love this environment! There are just a few tools I'm missing. Here's a
test: What's your guess on how many downloads BMPKIT.ZIP will get? That'll
be some indication of how much this tool was needed.
George
Don,
I think that VB's support for the printer could be vastly improved by
simply making VB a little more object oriented. In other words, the
different objects (Printer, Form, Debug) should be able to be passed in the
same manner. Right now that's not possible, so to make output that
normally goes to a form go to the printer, we either have to duplicate a
lot of code (not a good solution), use the .hDC property (better, but that
means we have to use API stuff to do anything), or just dump the bitmap to
the printer (but then you lose resolution). I've decided to just do all my
output to a metafile and then play that to whatever object is necessary.
Not a great solution, but it has the nice feature of keeping the full
resolution of the output device, and also I can save the graphics as a WMF.
– Ted
There are 2 Replies.
Ted,
Are you creating the metafile manually using API calls? That should
be fun code to read! -=- Jonathan
There is 1 Reply.
Jonathan,
Noooo….I'm not creating the metafile manually..yes, that certainly would
be "fun" code to read! No, I'm just doing a CreateMetaFile and then
directing my normal GDI output to the returned handle. Then when I close
it, I get a handle to the metafile which I can then Play into another hDC.
– Ted
There is 1 Reply.
Ted,
Any you can easily save this as a WMF file? Which WMF format are we
speaking of? -=- Jonathan
There is 1 Reply.
Jonathan,
I haven't tried it yet (for now metafiles are only used internally in my
app), but there's a CopyMetaFile function which tkes the handle to the
source filename and an null-terminated string for a filename, and according
to the docs: "…copies the source metafile to the file pointed to by the
lpFilename parameter…" Looks like a piece of cake! In fact, during the
CreateMetaFile call, you can give it a filename right there so it will
record the metafile directly to a file, otherwise you pass a NULL and it's
recorded in memory.
I do hate the documentation about metafiles though…they say which GDI
functions can be used, but they don't have a list of those that CAN'T be
used…I had to sit down and make such a list myself since I always find it
easier to look at a list of functions that I can't use so I can make sure I
plan around them.
– Ted
There is 1 Reply.
Ted,
I *think* that the CopyMetaFile function creates the "old" style WMF
file, rather than the nice resizable ones, but I don't know. That is some
special format introduced by Adobe, I think. Anyway, keep me informed as
to your progress. -=- Jonathan
There are 2 Replies.
Jonathan,
Yeah, I'm not sure what the differences are between the apparent different
WMF formats. Once I start writing out WMFs, I'll also get info on the
resizable WMF if CopyMetaFile does indeed write non-sizeable WMFs. I know
that the specified format (METAFILESTRUCT) includes the mapping mode and
the x/y extents, though it seems to me programs could just ignore that.
– Ted
There is 1 Reply.
Ted,
Well, good luck and keep me informed as to your progress on this
issue! I wonder…the .Picture property is a handle to a bitmap when the
the picture box contains a bitmap. Is it a valid metafile handle when it
contains a metafile? Hmmm. Bears further thoughts…Don!!! -=- Jonathan
Jonathan & Ted: I have experimented with metafiles from VB and their import
into other programs. A .WMF file as created by Corel and Designer has what
is called an Aldus header. This header includes the default sizing and
scaling info for the metafiles. The programs that I have played with that
accept metafile import such as WFW, AMI, PM4, and even VB want metafiles
with the Aldus header.
I haven't found any docs about the Aldus header, but did find sample
source code in MSOPSYS. Its not too hard to create a .WMF file, in fact
was going to do one in a project for the HT book, but didn't discover how
to until after the deadline.
BTW, received by QCWIN. Its good but really makes you appreciate the
elegance of VB.
… Dan
Dan,
Thanks for the info. I knew there was a special header name. I
always get Aldus and Adobe mixed up! Where was the source file over in
MSOPSYS? -=- Jonathan
There is 1 Reply.
Hi Ted,
This came up in the beta but for some reason it did not get added. I
think this would be a nice feature. I coded for a whole day thinking that I
could pass the PRINTER\PICTURE object to a Sub and print to the correct
output but lo and behold…
I will add this to the "wish list".
Don Funk