• Advertisement

Archived

This topic is now archived and is closed to further replies.

Micro$oft ##@$!@$ "features"

This topic is 5560 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. Sorry if I seem a bit upset, I am, due to Micro$ofts "features". I am trying to do some graphics programming in VB6, and microsoft ''magically'' every now and then screws up the image. I''ll describe it below, if any of you have encountered this, and found a solution, it would be greatly appreciated! It has to do with this statement "PictureNew=PictureOld" screwing up every now and then (i.e., the image becomes ''distorted''). (Both are picturebox controls) Basically (due to the code length, I am just describing it here) -- I use API calls to do the graphics (GetDIBits and SetDIBits) after doing image processing. When I want to ''refresh'' the original image (i.e., restore it), I set "PictureNew" (what the user sees) to the "PictureOld". BUT -- if I now try and do any image processing on the ''new'' "PictureNew" (the image that was just reset) -- it screws up and only processes *part* of the image. (I.e., it only processes 50% of the image). If I *redo* it, *then* it works -- but I don''t want to have to "redo" everything *any* time I make a change, etc... So, a) do you understand what I mean (or need more info?) b) do you have a solution? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
i never had a problem like this... could you post a bit of source code (just the important parts of course)?

Share this post


Link to post
Share on other sites
Sounds like an InvalidateRect problem. See if when you move the window off-screen (or another window on top of it) fixes this problem--or makes it look worse.

BTW, nice use of the $.

Every time you accuse Microsoft of something that''s actually your fault, God kills a kitten. Please, think of the kittens.

Share this post


Link to post
Share on other sites
quote:
Original post by Stoffel
Every time you accuse Microsoft of something that''s actually your fault, God kills a kitten. Please, think of the kittens.

glad to find yet another way to kill a kitten... i will now curse at bill gates between running batches...

Share this post


Link to post
Share on other sites
ha hah ha...

No no no no no... *not* a lack of skills... *that* i know!
It''s a wondrous "we are micro$oft, and feel like screwing up your
program bug"...

*basically*, providing pseudo code (if I provided all the code, it
would be a lot to go through)... basically have/do the following:

'' I load two pictures (identical) (picturebox controls)
PictureBox1.Picture = LoadPicture("blahblah.jpg")
PictureBox2.Picture = LoadPicture("blahblah.jpg")

'' Then, I get a copy of the image into an array
GetDIBits (blah blah blah (on PictureBox1))

'' I do my image manipulation
imageStuff

'' Then I set it back
SetDIBits (blah blah blah Setting PictureBox2).

''*THen*, if I want to go back to the *original* image,
'' I do:

PictureBox2 = PictureBox1

'' (I''ve also tried PictureBox2.Picture = PictureBox1.Picture, etc, which
'' sometimes seems to screw up more)...

*ANyways*... this method works pretty much most of the time, and
then all of the sudden, M$ screws up, and only half of my image gets
processed... (after having reset the image like above... if I don''t "reset"
the image, it works fine)...

Any ideas? Or is their some other way (fast) that I should be resetting
the picture?

Speaking of which,
2nd Question)
Is there a ''good'' way of resizing a picture box control? If I use
the ''autodraw''/''autosize'' properties -- if I am *loading in* a new
image, it appears to work a-ok. But if I actually, say just wanted
to either ''crop'' my image, whatever, and do Picture1.Width = 500,
after about 10-15 times, my program crashes, which I am *assuming*
is some kind of wierd memory leak, or not exactly how M$ works...

Share this post


Link to post
Share on other sites
Why don''t you people see that Microsoft IS trying to screw developers over?! _Obviously_, Microsoft wants to make it extremely difficult for people to program on their platform because then developers will get tired of all the purposeful bugs and then say, ''screw MS'' and code for Unix or something. I don''t understand why no one can see this?!

Share this post


Link to post
Share on other sites
Sorry, I should''ve seen that all this can''t possibly be your own fault. After all, you obviously don''t lack the skills to program a powerful VB picturebox app. I see now that it''s impossible that -you- made a mistake, and that Microsoft is to blame for everyone''s VB bugs.

Share this post


Link to post
Share on other sites
johnnyboy -

If you just want to load the original picture back into PictureBox2, why don't you store the filename of the picture loaded into PictureBox1 and then do a PictureBox2.Picture = LoadPicture(PictureFilename) everytime you want to reset the picture?

For your program crashing/resizing bug, make sure you're up to date on the service packs. There were 5 of them for Visual Studio 6. I'd have to see precisely what you're doing for resizing to be of more help here.

Another thing you might want to research is the command BitBlt() from the Windows API. If you're doing picture manipulations without DirectX's support, this command will be a lifesaver. It should also be able to handle resizes/crops without any problems since it works by copying an area of the source picture to an area of the destination picture.

Hope that helps


Current Projects:
- Ariene GE (72%): Adding material library effects..


[edited by - Tri on December 2, 2002 10:13:19 PM]

Share this post


Link to post
Share on other sites
Well, baas pap, if you are so enlightened, please do share
how to resolve the issue, rather than try to come up with
a witty retort that only makes you look foolish.

Rather than spending hours re-inventing the wheel, and
redesign a picturebox, it made sense to use this component
and expand upon it. It's called using your 'brain'. Do you know
what that means?

Incidentally, have you programmed for very long? If you knew
anything about developing under an MS platform, you would
know that they quite frequently have 'hidden' API's, incomplete
API's, documentation that even from their *own* MSDN CD doesn't
work (including basic commands, not talking anything sophisticated).
You must be new, so perhaps you should check out a different site,
because being able to turn on your Nintendo or Playstation and play
games does not make you a programmer.

[edited by - johnnyboy on December 2, 2002 10:21:46 PM]

Share this post


Link to post
Share on other sites
This is VB?

Try this:

Set PictureBox1.Picture = PictureBox2.Picture


That might help. I''m not sure though. I don''t know much about VB.

- Rob Loach
OverTech Technologies
-----------
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

Share this post


Link to post
Share on other sites
Or also, using the BitBlt API to copy the picture directly is bound to work.

- Rob Loach
OverTech Technologies
-----------
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

Share this post


Link to post
Share on other sites
Hi Tri --

Thanks for the feedback. Adding more info as requested:

1) For the picture box thing, I wanted a way to ''crop'' the size
of the picturebox. Turn both autodraw and autosize to false, and
then basically I would have something like:
Picture1.Picture = LoadPicture("abc.jpg")
Picture1.Width = Picture1.Image.Width
Picture1.Height = Picture1.Image.Height

If you say repeated that steps about 15 times (say with a picture
about 600x600), then after that all of the sudden your program will
crash. I used the above as a demonstration, but I can''t afford to
have my program ''crash'' if all I''ve done is load 15 different pictures
(or load it 15 times).

2) I thought about ''reloading'' the picture as you mentioned, but not
really feasible for a couple reasons, i) disk seek times (constantly reloading
a picture, would slow it down way too much), ii) if I make changes to the
image, then I''d have to save/load/save/load, etc.

3) With bltbit -- I did try that, and all I got was *really* strange errors.
On the surface it appeared to work (worked great on my Pentium-II), but
then as soon as I tried it on a different system (Celeron -- I really don''t know
if the chips make a differenence (i.e., floating point instructions perhaps?)
or if it''s the graphics cards themselves) -- but as soon as I tried it --
it was incorrectly reading the bitmap information from the image (i.e., saying
only "2" color planes instead of "3"/24-bit image), and would subsequently
foul up the program. I had not made *any* code changes -- it was just reading
it that way, and I have no idea why... ... so I had to find a different way
of doing it -- any ideas why bitblt would do that?



Share this post


Link to post
Share on other sites
Hi Rob --

Thanks for your reply, have tried that. Are you a C++ programmer?

I''m thinking I might just try this in C -- but don''t know how stable
that is (like, if you run into these kind of things with *VB*, what is
VC like??). If you''ve done any graphics programming (not directx/opengl,
I mean "graphics" programming) -- would you be able to direct me
to either some sample code of reading/writing images, etc, in VC++?

Share this post


Link to post
Share on other sites
Fox --

Thank-you for your reply, but that''s not really useful.
What other products would you suggest, or do have a solution
(either VB or VC++) to that?

Thanks.

Share this post


Link to post
Share on other sites
1) It sounds like you''re running out of memory when you do this. 15 pictures @ 600x600 requires a significant amount of storage space, both in memory and on disk, especially if you use the .BMP format.

The solution might be to unload the existing picture first (if you''re replacing the picture, that is) and then load the new picture. If there isn''t an Unload() or Dispose() command somewhere, try setting the Picture or Image property to Nothing (VB''s equivalent of null).

You could also try preloading all 15 pictures before-hand, though that''s bound to cause errors with Windows'' paging seeing the memory requirements involved.

2) What type of application are you making? If you''re making a game, you need to use BitBlt. No other type of application I can think of requires that much speed (for one that VB is making, anyways).

3) The first thing I can think of is that the Celeron machine might not have had its Colour Depth set appropriately in the Display Properties of the Control Panel. Try adjusting that value to either 24-bit or 32-bit. I generally try to avoid 24-bit formats (weird 2^x number, makes me uncomfortable) and tend to use either 16- or 32-bit formats instead.

CPU chips shouldn''t make any difference on BitBlt(), and neither should graphics cards either (unless you have a *really* old card), since BitBlt() is a core function which should work the same on all machines.

Share this post


Link to post
Share on other sites
Stoffel,

Thanks for the reply... Could you please expand more upon what
you mean by the ''invalidrect'' problem? (I don''t think I''ve ever heard
of that). Are you saying something like making the picturebox invisible,
changing it, then making it visible again?

Also, yeah, re: the M$, sometimes that''s how it feels.
(Money money money! You don''t *really* need Win98.
But we decided to make BLOATWARE just for you!
And any apps you use now, TOO BAD! don''t work with 95!
And guess what! We now have XP!!!! Ok, I''m exagerating
a little bit... but still... there''s truth to that...) Plus, with all their
licensing. (I.e., "subscription". ''Subscribe'' to our software,
and if you don''t, well, too bad for you!)

And programming in M$, at one time it was like this.

Turn on computer.
Oops, invalid page fault, reboot.
Turn on computer.
Oops, missing stack something or other, reboot.
Turn on computer.
Frozen at the long screen.
Turn on computer, wow. It loads up.
Load in VB, etc. Start programming, oops. The computer
just resets itself.
...
2 hours later...
...

Share this post


Link to post
Share on other sites
Hi Tri --

Thanks --

1) Tried using the equivalent of a dispose (i.e., Picture1.Picture = vbNull) --
that doesn''t work (also tried just plain "null"). I was thinking of doing something
like: Unload Picture1, and then ''recreating'' a new picture object, but I seem
to remember reading somewhere that that is not ''good''... so -- any other
ideas on how to dispose of an ''image'' object, without actually affecting the
picture object? (Yes -- I was thinking it was a memory thing too -- and that
is I believe what it is... Thing is, it ''should''nt'' be doing that as far as I know...)
Any other ideas?

2&3) Tried using BitBlt -- but the thing here is -- I did check the color settings
in the control panel, but the way the software was working is it checked the
resolution of the ''image'', not the color depth of the machine. (I.e., if I had an
8-bit bitmap, even if it was 24/32 bit color, it would give a value of "1". For
a 16-bit, value of 2, and 24-bit/32-bit, value of 3 (the color indexing. I.e.,
whether it was 1 byte in an indexed palette, 2 bytes for 65536 colors (again
a palette), or ''true'' color with RGB values (3 bytes). It was ''reading'' the image
as only being 2 bytes on the celeron, and 3 bytes on the pentium.

*Weird* bug.

I''ve done a workaround -- but bitblt does not seem to work/be cross-compatible.

Share this post


Link to post
Share on other sites
I''m not exactly sure what you are trying to do, but if all else false, try...

http://planetsourcecode.com

Good luck,

- Rob Loach
OverTech Technologies
-----------
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

Share this post


Link to post
Share on other sites
quote:
Original post by johnnyboy
*Weird* bug.


i think it''s a feature.

Share this post


Link to post
Share on other sites
Hi Rob,

THanks, yes -- I''ve gone there... it is just a matter of finding
some ''quality'' stuff though (there is a *lot* there, and some
is good, but haven''t yet found anything that I could learn from)...
any other ideas?

Share this post


Link to post
Share on other sites
Using DIB to copy it byte by byte? That would be the hardcore long route though .

GetPixel and SetPixel? That takes forever .

Try this:

This is in VB. I don''t know how to use StdPicture in C++.

Dim tmpPic as StdPicture
Set tmpPic = PictureBox1.Picture
PictureBox2.Picture = tmpPic

//OR if that doesn''t work, try saving the .Picture as a file, and loading it fromt eh file and deleting again.


I hope that helped a bit.

- Rob Loach
OverTech Technologies
-----------
"Life moves pretty fast. If you don''t stop and look around once in awhile, you could miss it."
- Ferris Bueller

Share this post


Link to post
Share on other sites
The only way you are going to solve this problem is by using either BitBlt or VB''s PaintPicture function. You must actually copy the pixels from your 2nd picture to your 1st picture. You cannot simply

Set PictureBox1.Picture = PictureBox2.Picture

because now both your picture objects are both pointing to the same picture object in memory. And you want to always have 2 pictures in memory, with 1 picturebox object pointing to each one. This is so you can have 1 to manipulate and 1 as a backup for your "undo" function.

Share this post


Link to post
Share on other sites
quote:
Original post by johnnyboy
Well, baas pap, if you are so enlightened, please do share
how to resolve the issue, rather than try to come up with
a witty retort that only makes you look foolish.

Rather than spending hours re-inventing the wheel, and
redesign a picturebox, it made sense to use this component
and expand upon it. It''s called using your ''brain''. Do you know
what that means?

Incidentally, have you programmed for very long? If you knew
anything about developing under an MS platform, you would
know that they quite frequently have ''hidden'' API''s, incomplete
API''s, documentation that even from their *own* MSDN CD doesn''t
work (including basic commands, not talking anything sophisticated).
You must be new, so perhaps you should check out a different site,
because being able to turn on your Nintendo or Playstation and play
games does not make you a programmer.



Hit a nerve there, didn''t I? Since you obviously know nothing about me, the amount of years that I have programmed and what I can or cannot do, I won''t even comment on your poorly based arguments.

I never suggested you should reinvent the wheel and not use existing components. You pulled that out of thin air. So please base your own ''witty retorts'' on something, before calling me foolish.

Anyway, I realize you fall in the "Microsoft bashing makes me a 1337 hax0r" category, so I''ll refrain from trying to reason with you.

Share this post


Link to post
Share on other sites

This topic is 5560 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Guest
This topic is now closed to further replies.

  • Advertisement