Determining default style properties

Discussion in 'Javascript' started by Dr_KralNOSPAM@nyc.rr.com, Jan 19, 2010.

  1. Guest

    Determining default style properties


    I know that one can use JS to determine various properties of the DOM.
    E.g., suppose one has:
    <p id='qwe' style="color:green">filler</p>
    then
    something= document.getElementById("qwe").style.color
    returns 'green'.

    But if one has
    <style> .setcolor {color:pink} </style>
    <p id='qwe' class='setcolor'>filler</p>
    something= document.getElementById("qwe").style.color
    gets an empty string rather that the set color of 'pink'.

    Similarly, one does not get any information about the browser's default
    setting or any other setting given indirectly.

    I have tried going up a level with
    document.getElementById("qwe").parentNode.style.color
    but that does not help. Nor does using
    document.getElementById("qwe")getAttribute("style")
    do any better in FireFox and in IE it just returns [object]

    Surely that information must be there for the browser use it. Is it
    accessible in any practical way?

    One could, of course, set everything at the topmost level of <body> but
    that would override the user's default settings which is most undesirable
    (and rude).

    TIA
     
    , Jan 19, 2010
    #1
    1. Advertising

  2. Scott Sauyet Guest

    On Jan 19, 10:28 am, wrote:
    > Determining default style properties
    >
    > But if one has
    >   <style>  .setcolor {color:pink}  </style>
    >   <p id='qwe' class='setcolor'>filler</p>
    > something= document.getElementById("qwe").style.color
    > gets an empty string rather that the set color of 'pink'.


    As happens so often in browser scripting, there are competing ways of
    doing this. The W3C-defined method is

    getComputedStyle

    specified here:

    http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSview-getComputedStyle

    and explained better here:

    https://developer.mozilla.org/en/DOM/window.getComputedStyle

    Internet Explorer has the property

    currentStyle

    which is documented here:

    http://msdn.microsoft.com/en-us/library/ms535231(VS.85).aspx

    There are plenty of examples (of varying degrees of correctness and
    efficiency!) online describing how you might combine these two into
    your own function.

    -- Scott
     
    Scott Sauyet, Jan 19, 2010
    #2
    1. Advertising

  3. Guest

    On Tue, 19 Jan 2010 08:07:40 -0800 (PST), Scott Sauyet
    <> wrote in
    <>:

    >On Jan 19, 10:28 am, wrote:
    >> Determining default style properties


    >As happens so often in browser scripting, there are competing ways of
    >doing this. The W3C-defined method is
    > getComputedStyle
    >
    >Internet Explorer has the property
    > currentStyle


    Scott,

    Thank you. Those two expressions and my friend google and your link do
    provide the needed answer.

    K.
     
    , Jan 19, 2010
    #3
  4. David Mark Guest

    On Jan 19, 11:07 am, Scott Sauyet <> wrote:
    > On Jan 19, 10:28 am, wrote:
    >
    > > Determining default style properties

    >
    > > But if one has
    > > <style> .setcolor {color:pink} </style>
    > > <p id='qwe' class='setcolor'>filler</p>
    > > something= document.getElementById("qwe").style.color
    > > gets an empty string rather that the set color of 'pink'.

    >
    > As happens so often in browser scripting, there are competing ways of
    > doing this. The W3C-defined method is
    >
    > getComputedStyle
    >
    > specified here:
    >
    > http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSview-getComput...
    >
    > and explained better here:
    >
    > https://developer.mozilla.org/en/DOM/window.getComputedStyle
    >
    > Internet Explorer has the property
    >
    > currentStyle
    >
    > which is documented here:
    >
    > http://msdn.microsoft.com/en-us/library/ms535231(VS.85).aspx
    >
    > There are plenty of examples (of varying degrees of correctness and
    > efficiency!) online describing how you might combine these two into
    > your own function.
    >


    More like there are ten tons of bad examples. Where's one good
    article (or example?) It's non-trivial to write a solid
    getComputedStyle wrapper, even when limited to dealing with a handful
    of styles (and apps should be designed with that in mind).

    So if your design dictates a comprehensive cross-browser
    getComputedStyle wrapper, change the design as it's a hard way to go.
     
    David Mark, Jan 20, 2010
    #4
  5. Scott Sauyet Guest

    On Jan 20, 7:50 am, David Mark <> wrote:
    > On Jan 19, 11:07 am, Scott Sauyet <> wrote:
    >> On Jan 19, 10:28 am, wrote:
    >>> Determining default style properties

    >>
    >>     getComputedStyle
    >>     currentStyle

    >
    >> There are plenty of examples (of varying degrees of correctness and
    >> efficiency!) online describing how you might combine these two into
    >> your own function.

    >
    > More like there are ten tons of bad examples.  Where's one good
    > article (or example?)  It's non-trivial to write a solid
    > getComputedStyle wrapper, even when limited to dealing with a handful
    > of styles (and apps should be designed with that in mind).


    This is true. If anything, it's an understatement.

    A few things you will probably have to keep in mind:

    - "opacity" is expressed in some places as a decimal, others as a
    percentage, and it is handled very differently in IE than in most
    other browsers.

    - "float" will require special handling (search for "cssFloat" and
    "styleFloat").

    - inheritable properties may require you to walk up the DOM to
    find them defined.

    - You have to decide how to handle children of elements with
    "display: none" that themselves have some other display value.

    - You'll have to deal with the difference in name formats between
    JS and CSS: "backgroundColor" vs "background-color".

    And that is probably just the tip of the iceberg.

    > So if your design dictates a comprehensive cross-browser
    > getComputedStyle wrapper, change the design as it's a hard way to go.


    If on the other hand, you have only a limited number of properties you
    need to support, it may not be too bad.

    Good luck,

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #5
  6. David Mark Guest

    On Jan 20, 10:08 am, Scott Sauyet <> wrote:
    > On Jan 20, 7:50 am, David Mark <> wrote:
    >
    > > On Jan 19, 11:07 am, Scott Sauyet <> wrote:
    > >> On Jan 19, 10:28 am, wrote:
    > >>> Determining default style properties

    >
    > >> getComputedStyle
    > >> currentStyle

    >
    > >> There are plenty of examples (of varying degrees of correctness and
    > >> efficiency!) online describing how you might combine these two into
    > >> your own function.

    >
    > > More like there are ten tons of bad examples. Where's one good
    > > article (or example?) It's non-trivial to write a solid
    > > getComputedStyle wrapper, even when limited to dealing with a handful
    > > of styles (and apps should be designed with that in mind).

    >
    > This is true. If anything, it's an understatement.


    Agreed.

    >
    > A few things you will probably have to keep in mind:
    >
    > - "opacity" is expressed in some places as a decimal, others as a
    > percentage, and it is handled very differently in IE than in most
    > other browsers.


    Yes, and among older non-IE browsers. But this is not specific to
    computing styles (just inherent to style in general).

    >
    > - "float" will require special handling (search for "cssFloat" and
    > "styleFloat").


    Yes.

    >
    > - inheritable properties may require you to walk up the DOM to
    > find them defined.


    Right, among other calculations (some impossible) that would be
    required convert a "cascaded" style to proper computed value. It's
    one of those things that is half-assed in the "standard" libraries.
    Some make no distinction between them at all (and no comments or
    documentation to indicate the shortcomings).

    >
    > - You have to decide how to handle children of elements with
    > "display: none" that themselves have some other display value.


    There's nothing to decide. See the CSS specs. :)

    >
    > - You'll have to deal with the difference in name formats between
    > JS and CSS: "backgroundColor" vs "background-color".


    Perhaps. It makes for a friendlier interface for beginners used to
    reading CSS, but not JS. I've never bothered with it at all.

    >
    > And that is probably just the tip of the iceberg.


    Pretty much. The computing of styles to compensate for IE's
    shortcomings is a major can of worms. That's why it is best to
    identify what you need out of a wrapper like this before you design
    it. If, for example, left and top will always be in pixels, you know
    you can get left and top reliably in cross-browser fashion (for
    browsers that support getComputedStyle or IE). Set the inline styles
    to pixel-based values and you can support the browsers that predate
    getComputedStyle. Context and simplicity are everything with this
    stuff, which is why outlandish, complex, half-assed error-prone
    nightmare scripts (that must be swapped out in their entirety every
    six months) are the opposite of a good idea. Yes, there are a lot of
    people out there who have yet to have this epiphany. It's coming. ;)

    >
    > > So if your design dictates a comprehensive cross-browser
    > > getComputedStyle wrapper, change the design as it's a hard way to go.

    >
    > If on the other hand, you have only a limited number of properties you
    > need to support, it may not be too bad.
    >


    Exactly.
     
    David Mark, Jan 20, 2010
    #6
  7. Scott Sauyet Guest

    On Jan 20, 10:25 am, David Mark <> wrote:
    > On Jan 20, 10:08 am, Scott Sauyet <> wrote:
    >> [ ... much agreement deleted ... ]
    >>     - You have to decide how to handle children of elements with
    >> "display: none" that themselves have some other display value.

    >
    > There's nothing to decide.  See the CSS specs.  :)


    I don't think the CSS specs can determine how getComputedStyle or the
    OP's own wrapper should behave.

    Each time I've written such a wrapper, I've reported "none" for

    <p style="display:none"><a id="myLink">something</a> more</p>
    ...
    var myLink = document.getElementById("myLink");
    alert(myGetComputedStyleWrapper(myLink, "display"));

    even though the underlying functions might report "inline". This has
    been useful behavior for my own applications. That's what I meant by
    deciding how to handle it.

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #7
  8. David Mark Guest

    On Jan 20, 11:35 am, Scott Sauyet <> wrote:
    > On Jan 20, 10:25 am, David Mark <> wrote:
    >
    > > On Jan 20, 10:08 am, Scott Sauyet <> wrote:
    > >> [ ... much agreement deleted ... ]
    > >> - You have to decide how to handle children of elements with
    > >> "display: none" that themselves have some other display value.

    >
    > > There's nothing to decide. See the CSS specs. :)

    >
    > I don't think the CSS specs can determine how getComputedStyle or the
    > OP's own wrapper should behave.


    Not the wrapper, but the inheritance rules are clearly defined in the
    specs. But you would have to move up to the DOM specs to get the
    specific recommendations for getComputedStyle.

    >
    > Each time I've written such a wrapper, I've reported "none" for
    >
    > <p style="display:none"><a id="myLink">something</a> more</p>
    > ...
    > var myLink = document.getElementById("myLink");
    > alert(myGetComputedStyleWrapper(myLink, "display"));
    >
    > even though the underlying functions might report "inline".


    The computed style is "none." That's in the specs. ;) IE would
    report "inline" as it doesn't compute styles.

    > This has
    > been useful behavior for my own applications. That's what I meant by
    > deciding how to handle it.
    >


    Sure, you could decide to not worry about descendants of elements with
    display:none style. That's certainly do-able for most (if not all)
    designs.
     
    David Mark, Jan 20, 2010
    #8
  9. Scott Sauyet Guest

    On Jan 20, 11:49 am, David Mark <> wrote:
    > On Jan 20, 11:35 am, Scott Sauyet <> wrote:
    >> Each time I've written such a wrapper, I've reported "none" for
    >>
    >>     <p style="display:none"><a id="myLink">something</a> more</p>
    >>     ...
    >>     var myLink = document.getElementById("myLink");
    >>     alert(myGetComputedStyleWrapper(myLink, "display"));
    >>
    >> even though the underlying functions might report "inline".

    >
    > The computed style is "none."  That's in the specs.  ;)


    I don't think so. There are slightly mixed signals

    http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display

    display { inherited: no }

    So children don't inherit "display: none" from their parents. However
    the same section says

    display: block
    ==============
    | This value causes an element to not appear in the formatting
    | structure (i.e., in visual media the element generates no boxes and
    | has no effect on layout). Descendant elements do not generate any
    | boxes either; the element and its content are removed from the
    | formatting structure entirely. This behavior cannot be overridden
    by
    | setting the 'display' property on the descendants.


    And this is why I like to report them as "display: none", it's not
    technically accurate, but it's generally more practical.


    > IE would report "inline" as it doesn't compute styles.


    So does every other browser I've tested. Not that I've gone to great
    lengths to test this, mind.

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #9
  10. David Mark Guest

    On Jan 20, 12:20 pm, Scott Sauyet <> wrote:
    > On Jan 20, 11:49 am, David Mark <> wrote:
    >
    > > On Jan 20, 11:35 am, Scott Sauyet <> wrote:
    > >> Each time I've written such a wrapper, I've reported "none" for

    >
    > >> <p style="display:none"><a id="myLink">something</a> more</p>
    > >> ...
    > >> var myLink = document.getElementById("myLink");
    > >> alert(myGetComputedStyleWrapper(myLink, "display"));

    >
    > >> even though the underlying functions might report "inline".

    >
    > > The computed style is "none." That's in the specs. ;)

    >
    > I don't think so. There are slightly mixed signals
    >
    > http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display
    >
    > display { inherited: no }
    >
    > So children don't inherit "display: none" from their parents.


    That's correct. But when you _compute_ the display style, you have to
    take the ancestors into account.

    > However
    > the same section says
    >
    > display: block
    > ==============
    > | This value causes an element to not appear in the formatting
    > | structure (i.e., in visual media the element generates no boxes and
    > | has no effect on layout). Descendant elements do not generate any
    > | boxes either; the element and its content are removed from the
    > | formatting structure entirely. This behavior cannot be overridden
    > by
    > | setting the 'display' property on the descendants.
    >
    > And this is why I like to report them as "display: none", it's not
    > technically accurate, but it's generally more practical.


    It is accurate if the computed display style is what you are after.

    >
    > > IE would report "inline" as it doesn't compute styles.

    >
    > So does every other browser I've tested. Not that I've gone to great
    > lengths to test this, mind.
    >


    What browsers (aside from IE) have you tested that reported "inline"
    for the anchor?
     
    David Mark, Jan 20, 2010
    #10
  11. David Mark wrote:

    > Scott Sauyet wrote:
    >> David Mark wrote:
    >> > Scott Sauyet wrote:
    >> >> Each time I've written such a wrapper, I've reported "none" for
    >> >>
    >> >> <p style="display:none"><a id="myLink">something</a> more</p>
    >> >> ...
    >> >> var myLink = document.getElementById("myLink");
    >> >> alert(myGetComputedStyleWrapper(myLink, "display"));
    >> >>
    >> >> even though the underlying functions might report "inline".
    >> >
    >> > The computed style is "none." That's in the specs. ;)

    >>
    >> I don't think so. There are slightly mixed signals
    >>
    >> http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display
    >>
    >> display { inherited: no }


    The cited section does not contain that line.

    >> So children don't inherit "display: none" from their parents.

    >
    > That's correct. But when you _compute_ the display style, you have to
    > take the ancestors into account.


    No. That is only the case if the property is inherited. `display' is a
    property that is not inherited. You mistake the computed value for
    something else.

    >> However the same section says
    >>
    >> display: block
    >> ==============
    >> | This value causes an element to not appear in the formatting
    >> | structure (i.e., in visual media the element generates no boxes and
    >> | has no effect on layout). Descendant elements do not generate any
    >> | boxes either; the element and its content are removed from the
    >> | formatting structure entirely. This behavior cannot be overridden
    >> | by setting the 'display' property on the descendants.
    >>
    >> And this is why I like to report them as "display: none", it's not
    >> technically accurate, but it's generally more practical.

    >
    > It is accurate if the computed display style is what you are after.


    No. The computed value of the `display' property of those child elements
    is "block" or whatever the default property value for the corresponding
    element is, not taking into account stylesheets that apply to that element.

    ISTM that Scott wants to compute what the CSS 2(.1) Specification calls the
    "actual value" instead:

    <http://www.w3.org/TR/CSS21/cascade.html#computed-value>


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Jan 20, 2010
    #11
  12. Scott Sauyet Guest

    On Jan 20, 12:51 pm, David Mark <> wrote:
    > On Jan 20, 12:20 pm, Scott Sauyet <> wrote:
    >> On Jan 20, 11:49 am, David Mark <> wrote:
    >> So children don't inherit "display: none" from their parents.

    >
    > That's correct.  But when you _compute_ the display style, you have to
    > take the ancestors into account.


    What specs are you referring to? I've never seen this specified.


    >>> IE would report "inline" as it doesn't compute styles.

    >
    >> So does every other browser I've tested.  Not that I've gone to great
    >> lengths to test this, mind.

    >
    > What browsers (aside from IE) have you tested that reported "inline"
    > for the anchor?


    Firefox, Chrome, Safari, and Opera.

    Is there something wrong with the following test?

    http://scott.sauyet.com/Javascript/Test/2010-01-20a/

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #12
  13. Scott Sauyet wrote:

    > David Mark wrote:
    >> Scott Sauyet wrote:
    >>> David Mark wrote:
    >>> So children don't inherit "display: none" from their parents.

    >>
    >> That's correct. But when you _compute_ the display style, you have to
    >> take the ancestors into account.

    >
    > What specs are you referring to? I've never seen this specified.


    For it is not specified so; David is mistaken here.

    >>>> IE would report "inline" as it doesn't compute styles.


    Non sequitur.

    >>> So does every other browser I've tested. Not that I've gone to great
    >>> lengths to test this, mind.

    >>
    >> What browsers (aside from IE) have you tested that reported "inline"
    >> for the anchor?

    >
    > Firefox, Chrome, Safari, and Opera.


    Works as designed.

    > Is there something wrong with the following test?
    >
    > http://scott.sauyet.com/Javascript/Test/2010-01-20a/


    Many things are wrong with it, but nothing that would invalidate your
    argument.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
     
    Thomas 'PointedEars' Lahn, Jan 20, 2010
    #13
  14. Scott Sauyet Guest

    On Jan 20, 1:29 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > ISTM that Scott wants to compute what the CSS 2(.1) Specification calls the
    > "actual value" instead:
    >
    > <http://www.w3.org/TR/CSS21/cascade.html#computed-value>


    Yes, although I don't know if that's what the OP would want or not.

    CSS2.1, now why in the world was I looking at 2.0? :) I knew there
    was some information on this.

    Thanks, Thomas.

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #14
  15. Scott Sauyet Guest

    On Jan 20, 1:49 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    >> Is there something wrong with the following test?

    >
    >>    http://scott.sauyet.com/Javascript/Test/2010-01-20a/

    >
    > Many things are wrong with it, but nothing that would invalidate your
    > argument.


    Fair enough. Looking at it again, I see several issues too. :)

    -- Scott
     
    Scott Sauyet, Jan 20, 2010
    #15
  16. David Mark Guest

    On Jan 20, 1:29 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > David Mark wrote:
    > > Scott Sauyet wrote:
    > >> David Mark wrote:
    > >> > Scott Sauyet wrote:
    > >> >> Each time I've written such a wrapper, I've reported "none" for

    >
    > >> >> <p style="display:none"><a id="myLink">something</a> more</p>
    > >> >> ...
    > >> >> var myLink = document.getElementById("myLink");
    > >> >> alert(myGetComputedStyleWrapper(myLink, "display"));

    >
    > >> >> even though the underlying functions might report "inline".

    >
    > >> > The computed style is "none." That's in the specs. ;)

    >
    > >> I don't think so. There are slightly mixed signals

    >
    > >> http://www.w3.org/TR/1998/REC-CSS2/visuren.html#propdef-display

    >
    > >> display { inherited: no }

    >
    > The cited section does not contain that line.
    >
    > >> So children don't inherit "display: none" from their parents.

    >
    > > That's correct. But when you _compute_ the display style, you have to
    > > take the ancestors into account.

    >
    > No. That is only the case if the property is inherited. `display' is a
    > property that is not inherited. You mistake the computed value for
    > something else.
    >
    > >> However the same section says

    >
    > >> display: block
    > >> ==============
    > >> | This value causes an element to not appear in the formatting
    > >> | structure (i.e., in visual media the element generates no boxes and
    > >> | has no effect on layout). Descendant elements do not generate any
    > >> | boxes either; the element and its content are removed from the
    > >> | formatting structure entirely. This behavior cannot be overridden
    > >> | by setting the 'display' property on the descendants.

    >
    > >> And this is why I like to report them as "display: none", it's not
    > >> technically accurate, but it's generally more practical.

    >
    > > It is accurate if the computed display style is what you are after.

    >
    > No. The computed value of the `display' property of those child elements
    > is "block" or whatever the default property value for the corresponding
    > element is, not taking into account stylesheets that apply to that element.
    >
    > ISTM that Scott wants to compute what the CSS 2(.1) Specification calls the
    > "actual value" instead:
    >
    > <http://www.w3.org/TR/CSS21/cascade.html#computed-value>


    Yes, I had that one screwed up. Unsurprisingly, I was thinking of
    some extraneous code that I shouid remove from My Library (been doing
    a bit of that lately). In this case, the computed value from the
    specs is what is returned by getComputedStyle (and it is not "none"),
    so I should not be compensating in the cascaded style (IE) branch.
    JFTR though, sometimes the expected result for getComputedStyle does
    not match what the specs call "computed".

    So the descendant is not displayed, regardless of display style, which
    might make it seem convenient to return 'none' for a get style
    wrapper. But if you consider the question during design, you don't
    need to worry about computing the display style of descendants (just
    check the ancestor). For example, imagine if you got a "none" result
    for an sncestor of an element with display:none, what would that mean
    to the caller? Setting its style to something other than "none" will
    have no effect. Empirically the ancestor is not displayed. Logically
    it is displayed and the proof is that if you display the ancestor, the
    descendant follows suit. If the descendant were not displayed,
    displaying the ancestor would not change that. I'm sure it is clear
    that designing around such questions is preferable to dealing with
    them at run time. ;)
     
    David Mark, Jan 20, 2010
    #16
  17. Scott Sauyet wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> ISTM that Scott wants to compute what the CSS 2(.1) Specification calls
    >> the "actual value" instead:
    >>
    >> <http://www.w3.org/TR/CSS21/cascade.html#computed-value>

    >
    > Yes, although I don't know if that's what the OP would want or not.
    >
    > CSS2.1, now why in the world was I looking at 2.0? :) I knew there
    > was some information on this.


    Although CSS 2.1 is still only a Candidate Recommendation as of today, for
    references as if still in the status of a Working Draft, the CSS 2 Errata
    document says that it should be considered the errata for CSS 2 where both
    versions define the same feature but differently:

    <http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html>

    However, several features of CSS 2.1 have been implemented already.

    > Thanks, Thomas.


    You are welcome.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Jan 20, 2010
    #17
  18. David Mark wrote:

    > JFTR though, sometimes the expected result for getComputedStyle does
    > not match what the specs call "computed".


    Please elaborate.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jan 22, 2010
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nathan Sokalski
    Replies:
    0
    Views:
    919
    Nathan Sokalski
    Oct 17, 2005
  2. John McMonagle
    Replies:
    11
    Views:
    593
    Paul Boddie
    Feb 12, 2006
  3. David C. Barber

    Determining the Default Printer

    David C. Barber, Nov 24, 2007, in forum: ASP .Net
    Replies:
    5
    Views:
    464
    Mark Rae [MVP]
    Nov 25, 2007
  4. Ken Varn
    Replies:
    0
    Views:
    472
    Ken Varn
    Apr 26, 2004
  5. Brian Mac
    Replies:
    0
    Views:
    127
    Brian Mac
    Apr 1, 2008
Loading...

Share This Page