#### Archived

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

# Micro$oft ##@$!@$"features" This topic is 5649 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 on other sites
i never had a problem like this... could you post a bit of source code (just the important parts of course)?

##### 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 If at first you don''t succeed.... blame Microsoft for your lack of skills! #### 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)

'' 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 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 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 on other sites
Simple answer to his ills is to stop using Microsoft products.

Dave Mark - President and Lead Designer
Intrinsic Algorithm -
"Reducing the world to mathematical equations!"
RIPPL Sports - NFL Statistical Analysis and Prediction System

##### 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 on other sites

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

This topic is now closed to further replies.

• 22
• 10
• 19
• 12
• 14