Every time I make a change affecting a toolbar (e.g. adding or removing
buttons), I loose the bitmap images at runtime. They are still displayed in
the designer, but when the application runs, the toolbar appears blank with
only separators visible. I determined that the problem is caused by the
wrong location of the toolbar.Buttons.AddRange function in the
auto-generated InitializeComponent function, which is placed before buttons
are initialized. If I manually move the AddRange function call after the
button initialization calls, it works fine, but the next time I make a
change, I have to do it again. This is really irritating. Is this a known
bug? Is there a fix for it? A better workaround? Thanks.

Alek

Re: Bug in Windows Form Designer generated code (VS.NET 2003) by hirf-spam-me-here

hirf-spam-me-here
Tue Jan 06 17:13:20 CST 2004

* "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> scripsit:
> Every time I make a change affecting a toolbar (e.g. adding or removing
> buttons), I loose the bitmap images at runtime. They are still displayed in
> the designer, but when the application runs, the toolbar appears blank with
> only separators visible. I determined that the problem is caused by the
> wrong location of the toolbar.Buttons.AddRange function in the
> auto-generated InitializeComponent function, which is placed before buttons
> are initialized. If I manually move the AddRange function call after the
> button initialization calls, it works fine, but the next time I make a
> change, I have to do it again. This is really irritating. Is this a known
> bug? Is there a fix for it? A better workaround? Thanks.

I am not able to repro that. Which version of VS.NET do you use? Are
you using Windows XP Visual Styles?

--
Herfried K. Wagner [MVP]
<http://www.mvps.org/dotnet>

Re: Bug in Windows Form Designer generated code (VS.NET 2003) by Doug

Doug
Tue Jan 06 18:31:50 CST 2004

Hi Alek,

The form designer is full of bugs of this nature (losing properties) that
seem to happen consistently with particular forms but with no obvious
pattern (to us anyway). Our usual solution is to move the incorrect or
missing code into the form constructor after the call to InitializeComponent
and forget about being able to design that particular aspect of the form.

Cheers

Doug Forster

"Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
news:OJEAsRK1DHA.3416@tk2msftngp13.phx.gbl...
> Every time I make a change affecting a toolbar (e.g. adding or removing
> buttons), I loose the bitmap images at runtime. They are still displayed
in
> the designer, but when the application runs, the toolbar appears blank
with
> only separators visible. I determined that the problem is caused by the
> wrong location of the toolbar.Buttons.AddRange function in the
> auto-generated InitializeComponent function, which is placed before
buttons
> are initialized. If I manually move the AddRange function call after the
> button initialization calls, it works fine, but the next time I make a
> change, I have to do it again. This is really irritating. Is this a known
> bug? Is there a fix for it? A better workaround? Thanks.
>
> Alek
>
>



Re: Bug in Windows Form Designer generated code (VS.NET 2003) by Alek

Alek
Tue Jan 06 18:34:48 CST 2004

I am using VS.NET 2003 v. 7.1.3008, Framework 1.1.4322, XP SP 1 (not sure
what visual styles are, so I guess I do not use them).

Alek

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:btfflf$5vq7b$6@ID-208219.news.uni-berlin.de...
> * "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> scripsit:
> > Every time I make a change affecting a toolbar (e.g. adding or removing
> > buttons), I loose the bitmap images at runtime. They are still displayed
in
> > the designer, but when the application runs, the toolbar appears blank
with
> > only separators visible. I determined that the problem is caused by the
> > wrong location of the toolbar.Buttons.AddRange function in the
> > auto-generated InitializeComponent function, which is placed before
buttons
> > are initialized. If I manually move the AddRange function call after the
> > button initialization calls, it works fine, but the next time I make a
> > change, I have to do it again. This is really irritating. Is this a
known
> > bug? Is there a fix for it? A better workaround? Thanks.
>
> I am not able to repro that. Which version of VS.NET do you use? Are
> you using Windows XP Visual Styles?
>
> --
> Herfried K. Wagner [MVP]
> <http://www.mvps.org/dotnet>



Re: Bug in Windows Form Designer generated code (VS.NET 2003) by Alek

Alek
Tue Jan 06 18:39:09 CST 2004

Thanks for the suggestion Doug. I will see if I can do something similar.

Alek

"Doug Forster" <doug_ZAPTHIS_AT_TONIQ_ZAPTHIS_co.nz> wrote in message
news:uLTmZVL1DHA.3496@TK2MSFTNGP11.phx.gbl...
> Hi Alek,
>
> The form designer is full of bugs of this nature (losing properties) that
> seem to happen consistently with particular forms but with no obvious
> pattern (to us anyway). Our usual solution is to move the incorrect or
> missing code into the form constructor after the call to
InitializeComponent
> and forget about being able to design that particular aspect of the form.
>
> Cheers
>
> Doug Forster
>
> "Alek Davis" <alek_xDOTx_davis_xATx_intel_xDOTx_com> wrote in message
> news:OJEAsRK1DHA.3416@tk2msftngp13.phx.gbl...
> > Every time I make a change affecting a toolbar (e.g. adding or removing
> > buttons), I loose the bitmap images at runtime. They are still displayed
> in
> > the designer, but when the application runs, the toolbar appears blank
> with
> > only separators visible. I determined that the problem is caused by the
> > wrong location of the toolbar.Buttons.AddRange function in the
> > auto-generated InitializeComponent function, which is placed before
> buttons
> > are initialized. If I manually move the AddRange function call after the
> > button initialization calls, it works fine, but the next time I make a
> > change, I have to do it again. This is really irritating. Is this a
known
> > bug? Is there a fix for it? A better workaround? Thanks.
> >
> > Alek
> >
> >
>
>