C# Discussion Boards - CodeProject

Dave Kreskowiak24-Mar-04 8:42

24-Mar-04 8:42

In a page with Frames, there are multiple web pages being used to render one visible page. There is a frames page that describes the layout of the view panes, then there is a seperate page for each of those panes. DocumentComplete will fire for every one of those pages that is downloaded, not just the frames page.

You can use the uRL property of the eventargs to compare to the URL you sent the browser to. If the page has frames, the last URL to be returned will be the one you originally sent the browser to:

    Private Sub AxWebBrowser1_DocumentComplete( _
            ByVal sender As Object, _
            ByVal e As AxSHDocVw.DWebBrowserEvents2_DocumentCompleteEvent) _
            Handles AxWebBrowser1.DocumentComplete
 
        If AxWebBrowser1.LocationURL = e.uRL Then
            MsgBox("Document Complete!")
        Else
            Debug.WriteLine("DocumentComplete received for URL: " & e.uRL)
        End If
    End Sub

RageInTheMachine9532

Heath Stewart24-Mar-04 9:03

24-Mar-04 9:03

You copied and pasted VB.NET code from the MS KB into a C# forum? You should be punished. Poke tongue | ;-P

Microsoft MVP, Visual C#
My Articles

Jeremy Kimball24-Mar-04 9:27

Jeremy Kimball

24-Mar-04 9:27

"Get the whips and chains! Bind the heathen!"

Smile | :)

Dave Kreskowiak24-Mar-04 9:28

24-Mar-04 9:28

Yes and No...

Yes, I pasted VB code into the C# Forum. AAAAAAAhhhhhh! My mistake! D'Oh! | :doh:

I should be flogged.

It's not the exact code from the MS KB. I found that the code in the KB was for VB6 and didn't translate very well to VB.NET. The .Object property wouldn't compile. So I changed it to use the URL properties instead. It can be fooled by a redirection in the original page, but that's shouldn't be too much of a concern.

RageInTheMachine9532

Heath Stewart24-Mar-04 9:29

24-Mar-04 9:29

Yeah, I know it's not a direct copy and paste. I've seen similar code around. Smile | :)

But, yes, you should be flogged. Rose | [Rose]

( oh, wait, I thought that was a cat-o-nine-tails... D'Oh! | :doh:

)

Microsoft MVP, Visual C#
My Articles

Dave Kreskowiak24-Mar-04 9:35

24-Mar-04 9:35

Whoops! How about a C# version...

private void AxWebBrowser1_DocumentComplete(object sender, AxSHDocVw.DWebBrowserEvents2_DocumentCompleteEvent e)
{
    if (AxWebBrowser1.LocationURL == e.uRL)
    {
        MsgBox("Document Complete!");
    }
    else
    {
        Degbug.WriteLine("DocumentComplete received for URL: " + e.uRL);
    }
}

My DEEPEST appologies to the C# community! Laugh | :laugh:

RageInTheMachine9532

Heath Stewart24-Mar-04 9:43

24-Mar-04 9:43

Okay, okay. Let me stitch you back up. Poke tongue | ;-P

Microsoft MVP, Visual C#
My Articles

Dave Kreskowiak24-Mar-04 9:50

24-Mar-04 9:50

Thank you master! Laugh | :laugh:

RageInTheMachine9532

Nick Parker24-Mar-04 17:35

Nick Parker

24-Mar-04 17:35

Ok, this is starting to definately go off the bounds of programming! Roll eyes | :rolleyes:

- Nick Parker
My Blog | My Articles

Component Text Property

dbetting24-Mar-04 6:28

dbetting

24-Mar-04 6:28

I have a custom component that is inheriting from System.Windows.Forms.UserControl. I would like to have the nice and consistent property Text rather than the property Caption.

Defining public string Caption works fine and I can view the property in design mode as expected. But if I replace the property definition with public override string Text, it doesn’t allow me to see the property.

What is the nuance that I’m missing?

Thanks
db

je_gonzalez24-Mar-04 7:54

24-Mar-04 7:54

try public new string Text...

Heath Stewart24-Mar-04 8:41

24-Mar-04 8:41

That's a bad idea. There is no reason to hide the Text property of the parent class and this will screw-up a lot of the implementation if the variables, fields, or properties to not specifically reference the derivative UserControl Type.

Microsoft MVP, Visual C#
My Articles

je_gonzalez24-Mar-04 8:55

24-Mar-04 8:55

And the world will end...

Nice to hear from you again!

Heath Stewart24-Mar-04 9:02

24-Mar-04 9:02

It may. The massive power outage on US's eastern seaboard was caused by a simple bug.

The solution is very simple and examining the UserControl class using something like ildasm.exe would resolve the problem. The member is being overridden simply to hide it from designers and code editors. It was still available all along even without having to override it in order to show it again.

Microsoft MVP, Visual C#
My Articles

je_gonzalez24-Mar-04 9:13

24-Mar-04 9:13

Probably written by a Californian.

Heath, I sincerely think that you need to RELAX. It may be the way I type, but you seem to treat things as way too important.

There is a radio show here in L.A. (yes, Lala land, home of Arnold the guvernor) where there is a guy who complains about everything and the question that everyone keeps asking him, and I ask you now, is "Who hurt you?".

PS: I forgot to admit that the bug in the electrical grid was mine, but being a Californian it was meant to run in the electical grid of Uzbekistan, and make the lights that were left on read out, "HS rules...", damn if I got it wrong again.

Heath Stewart24-Mar-04 9:18

24-Mar-04 9:18

je_gonzalez wrote:
Heath, I sincerely think that you need to RELAX

I'm not the only one. I wasn't offended by your remark. A lot of things I post in this forum are for posterity in case some n00b ever considers searching this forum first.

Laugh | :laugh:

That made me laugh. Oh well, here's to hoping... Beer | [beer]

Microsoft MVP, Visual C#
My Articles

je_gonzalez24-Mar-04 9:26

24-Mar-04 9:26

Let's see I was taught not to say RTFM to clients anymore two years before you were born. Yeap, things have changed, now is RTFF, as manuals have given way to forums.

Heath Stewart24-Mar-04 8:47

24-Mar-04 8:47

It looks like you're declaring a field, not a property. There is a difference. Also, UserControl in .NET 1.1 attributes the override with the BrowsableAttribute and the EditorBrowsableAttribute to merely hide it from designers and source code editors. It's still there and you can still call it. They removed it only from view because UserControls are typically container in which Text make little sense.

To show it again, declare your property like so:

[Browsable(true)]
[EditorBrowsable(EditorBrowsableState.Always)]
public override string Text
{
  get { return base.Text; }
  set { base.Text = value; }
}

You'll then see it again in both the designer and source code editor.

Microsoft MVP, Visual C#
My Articles

dbetting24-Mar-04 15:41

dbetting

24-Mar-04 15:41

Thanks. I was only using the Category, Description and Default attributes. Adding the Browsable and EditorBrowsable attributes did the trick.

Now that I've got it showing, testing has shown a couple other nuances.
1. Using Default doesn't do anything, it always contains the default object name as the default Text, regardless of the Default attribute. Even setting a line after InitializeComponent(); as Text="";, didn't do anything.
2. I would've been able to live with the Text property not being blank upon dropping the component on the form but not remembering its value just ain't cool. Initially I tried to use base.Text as the storage for the Text value (seemed the appropriate thing to do). Close the form and open it, the Text value is gone. Tried using a private variable instead, got the same result. Tried using new rather than override in both scenarios of base.Text and a private variable. The component still will not remember the value of Text. None of this affected Default either.

While answering this, can you tell me if there is a trick to finding info in the Help and/or SDKs? I suspect the answer you provided would've been there but, while there is probably everything I need to know at my finger tips, asking the right question seems to be the issue (thus RTFF seems to be a better solution than RTFM). Unfortunately, due to corporate bankrupcies I no longer have the team with which to collaborate (previously coded in Delphi) and some of the nuances of .Net have been somewhat frustrating to decipher.

Thanks again.

Heath Stewart24-Mar-04 17:08

24-Mar-04 17:08

These are all design-time attributes. The DefaultAttribute is there to facilitate resetting the property value. Using a method that returns a bool called ShouldSerializePropertyName also facilitates this goal.

Again, though, don't use new. Only use this when you want to hide a member. For instance, if you use new, any code that refers to your class as a Control (where Text is defined as a virtual method) or any other derivative of Control (before your class), then the virtual Text is used. Only when a variable is declared as your Type will your Text be used. Since much of the Windows Forms implementation refers to all child controls as Control types, your Text accessors wouldn't be called.

To note (since you obviously read the little flame war that shouldn't have been), I don't completely advocate RTFM. RTFM goes well with RTFF, but I'm a strong believer in teaching a man to fish, if you know what I mean. Reading the docs and understanding them (like the mostly consistent naming conventions, how C# relations to .NET and IL relates to the CLR, etc.) is very important, but there's also times when people get stuck - even the best have brain farts now and then.

The best thing to do is just skim the class library docs some time. Get to know where everything is. Also, whenever you have a question about a specific class, the help Index is your friend. Just type it in. Don't specify certain properties, though, like ScrollableControl.Text because it doesn't exist as a defined method of ScrollableControl - it's inherited. It will be in the member documentation for ScrollableControl but not in the index. It's just the way their help built system works (and even those like NDoc[^] which I occassionally contribute to and is very popular).

Once you get to know where all the classes are roughly and how everything is named, it's not too hard finding what you need if you can't remember or even if you don't know exactly what you're looking for.

Microsoft MVP, Visual C#
My Articles

version numbers

surgeproof24-Mar-04 6:22

surgeproof

24-Mar-04 6:22

this isn't directly c# linked as it can be applied to a lot of other languages, but there you go. when developing applications what do people normally name their versions as? major.minor.revision or also build number etc. i'd be interested to hear the standard or if there is one at all. also how do you cope with making patches (if you need to! Wink | ;)

) surely you wouldn't have to release a new program each time and send it?? can't you have some some of file that updates the original?

cheers,
surgeproof

-------------------------------------------------------
looking for hosting? ithium is good.

Re: version numbers

Michael Flanakin24-Mar-04 6:50

Michael Flanakin

24-Mar-04 6:50

As far as version numbers go, that kind of depends on how you build the app. What I prefer, is to have a nightly build process with version numbers that are <major>.<minor>.<months><days>. Any builds outside of this would be the same, appending .<24hr time>, or some other unique identifier. The <months> and <days> represent how many months and days you've been working on the <major>.<minor> version.

If I'm not using a scheduled build, I usually just do <major>.<minor>.*, which lets .NET decide what the rest should be. For larger apps, or those with frequent changes, that don't have scheduled builds, I'd do <major>.<minor>.<revision>.*.

Michael Flanakin
Web Log

Re: version numbers

surgeproof24-Mar-04 7:15

surgeproof

24-Mar-04 7:15

thanks, this helps. any ideas about the upgrade/patch routine? and also, do you name all the version yourself or incorporate it into the code? can't you type something like version.major in your code?

once again,
thanks.
surgeproof.

-------------------------------------------------------
looking for hosting? ithium is good.

Re: version numbers

Heath Stewart24-Mar-04 8:55