Run-time error '480'
in [Visual Basic]
|
Prev: Permissions again
Next: simple stopwach program
From: Webbiz on 10 Sep 2009 11:34 On Thu, 10 Sep 2009 15:52:22 +0100, "Dave O." <nobody(a)nowhere.com> wrote: > >"Webbiz" <nospam(a)forme.thanks.com> wrote in message >news:a13ia51he83d0pasgmt4h7lpbmfq3dmfrm(a)4ax.com... >> On Thu, 10 Sep 2009 10:02:59 +0100, "Mike Williams" >> <Mike(a)WhiskyAndCoke.com> wrote: > >>> ScaleMode errors such as this can often be >>>responsible for controls being set up to a size very much larger (or >>>smaller) than the size you have in mind. >> >> No size in mind as mentioned. Just fill the form and the form fills >> the display. > >How? >pic.width = form.width? >pic.width = form.scalewidth? >If either's the case you *really* do need to check for scalemode errors. > >An easy way to test: Make the picture box a contrasting colour then in the >sizing routine, subtract a number like 15 from the height and width, you >should have a line of form visible right & bottom, if not there is something >wrong. > >Dave O. > On the question, it's pic.width = form.scalewidth. I think your suggestion is meant to test if the picbox may be exceeding the scalewidth/height limits of the form. It's not. This app draws price charts that are dependent on using as much x/y as available within the picbox. Without having to color the background, my charts would be going off the page if this were a problem. Everything displays just fine. And to answer one of Mike's questions, in the Form's resize event I am setting .AutoRedraw = True. There was a reason for this, though too much time has elapsed to remember what it was. So what I've done is tested as best I can at FALSE. No change. And now commented out. No change. Since I use this app each day extensively, I'll just keep an eye on it and see if I can leave it like this. Thanks. Webbiz
From: Karl E. Peterson on 10 Sep 2009 18:41 Webbiz wrote: > I don't get it. How could this have been working all this time and > then suddenly, today, doing the same thing I do with it every day, > decide it is no longer going to work? Even old copies of my compiled > application now fails when I activate this tool. Because you haven't rebooted in [ages] and all the GDI handles have leaked. > But does anyone have any idea what could have changed that would cause > this to just now decide to stop working? Time for the ol' three-finger-salute, as we used to call it. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Webbiz on 10 Sep 2009 23:13 On Thu, 10 Sep 2009 15:41:41 -0700, "Karl E. Peterson" <karl(a)exmvps.org> wrote: >Webbiz wrote: >> I don't get it. How could this have been working all this time and >> then suddenly, today, doing the same thing I do with it every day, >> decide it is no longer going to work? Even old copies of my compiled >> application now fails when I activate this tool. > >Because you haven't rebooted in [ages] and all the GDI handles have leaked. > >> But does anyone have any idea what could have changed that would cause >> this to just now decide to stop working? > >Time for the ol' three-finger-salute, as we used to call it. Rebooting was done after I couldn't figure it out. But after the reboot, same issue. Weird. Really, really weird. :-) Webbiz
From: Clive Lumb on 11 Sep 2009 03:38 "Webbiz" <nospam(a)forme.thanks.com> a �crit dans le message de news: 61gja5dvipd27o0c7djuhhc78otq3o7pva(a)4ax.com... > On Thu, 10 Sep 2009 15:41:41 -0700, "Karl E. Peterson" > <karl(a)exmvps.org> wrote: > >>Webbiz wrote: >>> I don't get it. How could this have been working all this time and >>> then suddenly, today, doing the same thing I do with it every day, >>> decide it is no longer going to work? Even old copies of my compiled >>> application now fails when I activate this tool. >> >>Because you haven't rebooted in [ages] and all the GDI handles have >>leaked. >> >>> But does anyone have any idea what could have changed that would cause >>> this to just now decide to stop working? >> >>Time for the ol' three-finger-salute, as we used to call it. > > > Rebooting was done after I couldn't figure it out. But after the > reboot, same issue. Weird. Really, really weird. > > :-) > Webbiz Have you had a look at the font that you are using? It could be corrupt. This would explain why it borks when windows try to render it to get the width. It would also explain why older versions also show the same error. It could even be a broken graphics driver. Also if you are running Vista with non-standard screen dpi, anything can happen with VB6 apps. Hope one of these ideas helps.
From: Mike Williams on 11 Sep 2009 05:27
"Webbiz" <nospam(a)forme.thanks.com> wrote in message news:a13ia51he83d0pasgmt4h7lpbmfq3dmfrm(a)4ax.com... > It's the chart window and takes up virtually all the > space on the form. And the form is usually maximized. > And if it is relevant, my display is 22inch flat. It's the pixel size you are currently running at that matters, rather than the actual physical size. > Anyway, in another post I mention placing .AutoRedraw > to False at the point of entry to the routines that are triggered > by the button event. It seems to be working okay right now, > so I'll keep an eye on any adverse effects. That's because VB no longer needs to create the Autoredraw bitmap. If your app is still functioning correctly then you either did not need Autoredraw in the first place or you have altered your code in some way since you first actually did need Autoredraw. Perhaps you were originally using Autoredraw to maintain a persistent image and you are now instead redrawing your image in the container's Paint event. Even though the act of turning off Autoredraw on your apparently screen size PictureBox has solved your immediate problem it is still worth pinning it down further though, because unless you are using lots of other large Autoredraw bitmaps or are using lots of other GDI objects then you shouldn't have a problem with a single screen size bitmap, even on a fairly low spec machine. Also, if it turns out that your app currently does have a problem creating a single screen size Autoredraw bitmap then your whole app is sailing very close to the wind anyway as far as the GDI is concerned and solving the current problem by turning off Autoredraw on that single screen size object will probably gain you only a temporary solution and the problem will surely come back at a later stage. And if you are not using lots of GDI resources and if a single screen size bitmap on its own actually does turn out to be the cause of the problem (which would indicate that you are running on an extremely low spec machine) then you're going to need to take that fact into account throughout your entire program when you are considering which of the various different ways you should perform your required tasks. Anyway, before you go looking for other esoteric reasons I still think it is worth double checking that your code is not inadvertently trying to create an extremely large Autoredraw bitmap. What happens when you change your existing "With Tbox . . . EndWith" block as follows? What pixel size is reported in the MsgBox? With TBox Set FontContainer.Font = .Font MaxWidth = .Container.ScaleWidth - .Left With FontContainer MsgBox .ScaleX(.ScaleWidth, .ScaleMode, vbPixels) _ & " x " & .ScaleY(.ScaleHeight, .ScaleMode, vbPixels) End With MinWidth = FontContainer.TextWidth("XX") HeightOfLine = FontContainer.TextHeight("X") .Height = HeightOfLine .Width = MinWidth End With Mike |