Can't set button to Visible?

[Rob R. Ainscough]

Have a very strange problem.

I have a Web Forms Panel that contains an HTML GridLayout Panel, if I add a
button to the HTML GridLayout Panel it will not permit me to set the Visible
property = True. What is even more strange, I have another Web forms panel
that contains an HTML Gridlayout panel with a button, but this button
permits me to set the Visible property??

Any suggestion?

Thanks, Rob.

 

[Jay Douglas]

I've seen this same behavior before with controls in panels. This sometimes
happens if you have the panel visible set to false. I've gotten around this
issue by manually setting the panel visible to false in the Load event.

Also, test your page out and see if the button really does display or not..

Kind of a cludgy answer, but this has been my work around

 

[Rob R. Ainscough]

Jay,

Thank you, that resolved it. I'm almost tempted to install VS 2005 Beat 2,
it can't be worse than VS 2003 "release" version.

Just gotta keep reminding myself this is progress, and tell company CEO that
it really is better even if it takes longer to produce and is slower to
display in a browser -- it is a hard sell. Our migration to VS 2003 is
getting me into a lot of hot water from those concerned with results and
revenue. I just hope Microsoft's vision is clearer than my reality of the
blurred real world.

Thanks again for your help.

Rob.

 

[Jay Douglas]

I was in the same boat, I had to move the company I was working at from VB 6
(and some PHP/MySQL) to VS 2003 C# ... No easy task.

With OO programming, a rich IDE, and a huge community base, it was the best
decision we've ever made. Our application productivity has increased by
more than 200% over the past 2 years.

Out of the box the VS ASP.NET editor tries to get you to do everything in
grid layout and with panels. If I can offer any advice, don't create your
web applications in such a mode. Create you apps like a web developer, not
a winforms developer.

Other than that, the built in ASP.NET controls are awesome. With binding to
custom collections, and the ability to change the properties/characteristics
of a control in an easy code behind, I haven't found a business problem I
couldn't solve yet.

Two thumbs up.

There are a ton of third party controls available. MSD2D has recently
released their 2005 people choice awards for .net components.
Check it out:
http://msd2d.com/PeoplesChoice05.aspx?section=dotnet

 

[Rob R. Ainscough]

Jay,

Why do you recommend not using WebForms in GridLayout?

I've tried FlowLayout and find it terribly "hit and miss" with a ton of
extra work involved to make it look nice -- maybe if I get more involved in
Style sheets it would be easier -- I don't know. But I'm pretty frustrated
with switch to HTML mode, searching for my label so I can set the TEXT-ALIGN
or get the absolute Top or Left value. It boggles my mind these values are
made directly available via Properties box.

I haven't noticed any performance issues wtih WebForm GridLayout, but I'd
like to know why you want to create apps like a "web developer"?

I must admit I'm not a big fan of web development when compared to
WindowsForms, it just seems like a giant step backwards where I have to
manage session states, check connections, and always remember everything is
really a big interpretted script (something VB dropped a long time ago, but
it returns in web development) -- ironic. In other words, a lot of extra
coding and extra processing is required using ASP.NET technology with
VB.NET.

There are many times where I have seriously considered just putting my app
install links on our web site(s) that'll just down load very small footprint
..NET apps (assume .net framework v1.1 install) and do webinstalls which will
provide a much faster and more robust interface without the worry browser
settings, malicious adware, nor keeping web servers alive and all the
supporting security requirements. Since the next MS OS will include .NET
framework, I suspect MS are thinking along the same lines -- the IE browser
is bloated, full of security wholes and tempermental -- and who knows what
ActiveX and/or spyware has been loaded on the client's PC -- I certainly
know that most of the users our company interacts with have no clue if their
keystrokes are being sent off to some other web site and trying to tell them
they need to configure their browser in a certain way, etc. etc.

But, I keep hoping that someday MS will evolve rather than just keep
changing the syntax to get the same old jobs done with a slightly different
twist. But I agree, once the syntax is learned, I'm sure productivity will
increase 200%. But that process needs to improve, I've had to give up WAY
too many features from the old compared to working with VB.NET and ASP.NET
in any form. If I didn't have to re-learn a new technology, and MS opt'd to
upgrade an existing technology then I would guess I could have realized a
500% productivity increase. So taking into consideration where I would be
today on a "upgraded" existing platform vs. an "all new platform", then I
would have to say my production is 300% below my potential. I keep hearing
stories of people saying their productivity is up 200%, 300%, 10X, but
compared to what?? -- running the same unchanged 3yr old dev platform, sure
I can agree with that. But my point is how would you know where you'd be on
the productivity scale if the platform was "upgraded" rather than scraped
for the "all new, go faster model"?

I hope you're understanding my point, it's like creating re-useable code
that no one at MS ever re-uses and dumps for another set of "re-useable"
code -- ironic isn't it. So Microsoft are having a hard enough time making
their own dev platform code re-usable -- and that is what does not sit well
with me -- I've seen the pattern before.

Rob.