If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
The latter seems like it's going to work better for me, but I'm
wondering if there are any disadvantages of doing this.
This probably won't make that much difference on a real page, as my
current page is just a page to test the JavaScript components I'm
integrating. The real page it gets integrated into will have much more
information, such that the initial page height will be longer than the
initial visible area.
19  3954 
david.karr wrote:
If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
What is "current component set" and what does it mean for it to have a
"resulting small height"?
>
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
If the body has a margin, then you certainly do want to color the html
unless you want the body's margin to have the browser's default color.
On Aug 19, 12:12*pm, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
david.karr wrote:
If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
What is "current component set" and what does it mean for it to have a
"resulting small height"?
My test page defines two divs, one of which is initially populated,
and the other is empty. The only populated div is about 100 pixels
high. The rest of the page is blank. There's a big difference in the
result between setting background-color on the html element or the
body element.
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
If the body has a margin, then you certainly do want to color the html
unless you want the body's margin to have the browser's default color.
I want to control the background-color on the entire visible page.
Note that when I googled for questions like this, I found statements
that say it's not recommended to set background-color on the html
element, as opposed to the body element. They didn't say WHY, however.
david.karr wrote:
I want to control the background-color on the entire visible page.
Note that when I googled for questions like this, I found statements
that say it's not recommended to set background-color on the html
element, as opposed to the body element. They didn't say WHY, however.
Perhaps this is related to the fact that that some legacy browsers,
which are now extinct, did not support CSS applied to the HTML element.
david.karr wrote:
On Aug 19, 12:12 pm, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
>david.karr wrote:
>>If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
What is "current component set" and what does it mean for it to have a
"resulting small height"?
My test page defines two divs, one of which is initially populated,
and the other is empty. The only populated div is about 100 pixels
high. The rest of the page is blank. There's a big difference in the
result between setting background-color on the html element or the
body element.
>>However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
If the body has a margin, then you certainly do want to color the html
unless you want the body's margin to have the browser's default color.
I want to control the background-color on the entire visible page.
Note that when I googled for questions like this, I found statements
that say it's not recommended to set background-color on the html
element, as opposed to the body element. They didn't say WHY, however.
I don't know. But if you have margin: 0; for your body then it's six of
one and half a dozen of the other anyway.
On 8/19/2008 12:12 PM, Harlan Messinger wrote:
david.karr wrote:
>If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
What is "current component set" and what does it mean for it to have a
"resulting small height"?
>However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
If the body has a margin, then you certainly do want to color the html
unless you want the body's margin to have the browser's default color.
I created a very short page at
<http://www.rossde.com/test/bg_color.html>. This has an external CSS
file that sets both margins, background color, and background image on
BODY. With SeaMonkey 1.1.11, the entire viewing area shows the color
and image; they extend into the margins. Note that the default
background color that I set for my browser is quite distinct from the
background color specified in my CSS.
The W3C CSS1 specification states in Section 1.3:
"To set a "default" style property for a document, one can set the
property on an element from which all visible elements descend. In HTML
documents, the 'BODY' element can serve this function".
Thus, properties set for BODY apply to the entire viewing window and not
merely to the area within the margins.
--
David E. Ross
<http://www.rossde.com/>
Q: What's a President Bush cocktail?
A: Business on the rocks.
David E. Ross wrote:
On 8/19/2008 12:12 PM, Harlan Messinger wrote:
>david.karr wrote:
The W3C CSS1 specification states in Section 1.3:
"To set a "default" style property for a document, one can set the
property on an element from which all visible elements descend. In HTML
documents, the 'BODY' element can serve this function".
Thus, properties set for BODY apply to the entire viewing window and not
merely to the area within the margins.
CSS 1 is long obsolete. Designers and browser makers target CSS 2.1.
On Tue, 19 Aug 2008 09:41:24 -0700 (PDT)
"david.karr" <da**************@gmail.comwrote in:
<47**********************************@b30g2000prf. googlegroups.com>
If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
The latter seems like it's going to work better for me, but I'm
wondering if there are any disadvantages of doing this.
This probably won't make that much difference on a real page, as my
current page is just a page to test the JavaScript components I'm
integrating. The real page it gets integrated into will have much
more information, such that the initial page height will be longer
than the initial visible area.
What UA and version? Is this XHTML or HTML?
--
BootNic Tue Aug 19, 2008 06:54 pm
The world is very different now. For man holds in his mortal hands the
power to abolish all forms of human poverty, and all forms of human
life.
*John Fitzgerald Kennedy, Inaugural Address*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkirT0MACgkQylMUzZO6jeJOOQCfSbZPaJT617 8Q6GW9JHOiCs2t
LR4An3tBmsw2eW205iIc/UeLBAIlECr7
=1sXS
-----END PGP SIGNATURE-----
In article
<47**********************************@b30g2000prf. googlegroups.com>,
"david.karr" <da**************@gmail.comwrote:
If in my CSS I set the "background-color" property on the "body"
element, it only covers the background of the elements defined in the
body, up to the current width and height of the page. However, if the
current component set has a resulting small height, this leaves most
of the page with the original background color (white).
However, if I set the property on the "html" element instead, it does
color the entire visible page, beyond the current height of all the
components on the page.
The latter seems like it's going to work better for me, but I'm
wondering if there are any disadvantages of doing this.
If you have BODY smaller than HTML and you want the HTML to be a
different color to BODY then set both the colours you want explicitly on
the elements concerned. Otherwise, on BODY alone will normally do.
You are walking into a deep and dangerous area David. Just follow the
advice I give above and leave it be. I have seen grown men that have not
had the benefit of theological training fall apart from looking into
these matters.
Whatever you give to HTML will be appropriated by a higher being called
CANVAS. CANVAS is a law unto itself. HTML, we can surmise, will then
merely let the CANVAS's colour shine through it instead of it generating
its own. It will be a sort of moon (a sort that refracts rather than
reflects) rather than a light generating sun that we might otherwise
believe it is.
The CANVAS's penchant for appropriation - to use a polite term for
something more scurrilous - can be caught on film. It does its stealing
(perhaps we should not be so polite) quicker than the eye can see.
At great expense to myself, I have built an HTML Camera that can catch
what the earthling eye cannot. I have already published before one
particularly fast act of theft of a background image by CANVAS:
<http://dorayme.890m.com/rootStudies/imageTheft.html>
You see! You see what we are up against now?
--
dorayme
On 2008-08-19, Harlan Messinger <hm*******************@comcast.netwrote:
david.karr wrote:
>On Aug 19, 12:12 pm, Harlan Messinger
<hmessinger.removet...@comcast.netwrote:
>>david.karr wrote:
[...]
>My test page defines two divs, one of which is initially populated,
and the other is empty. The only populated div is about 100 pixels
high. The rest of the page is blank. There's a big difference in the
result between setting background-color on the html element or the
body element.
[...]
>Note that when I googled for questions like this, I found statements
that say it's not recommended to set background-color on the html
element, as opposed to the body element. They didn't say WHY, however.
I don't know. But if you have margin: 0; for your body then it's six of
one and half a dozen of the other anyway.
No it isn't. As David Karr pointed out in the first place, the
background on BODY goes on BODY. This means it extends no higher than
the contents of BODY, since that is the dimension of BODY (it's just a
normal flow block).
The background on the root element is instead applied to the canvas
(which means the bounding box of everything you can see or scroll to
from the main viewport).
There may be differences in some browsers and in quirks mode-- BODY's
background may have got applied to the canvas in some circumstances.
The canvas doesn't have an element, hence the special rule. This is a
similar situation to overflow, which if set on the root element is
actually applied to the viewport (the viewport, like the canvas, doesn't
have an element so instead it nicks certain properties from the root
element).
On 2008-08-19, David E. Ross <no****@nowhere.notwrote:
[...]
I created a very short page at
<http://www.rossde.com/test/bg_color.html>. This has an external CSS
file that sets both margins, background color, and background image on
BODY. With SeaMonkey 1.1.11, the entire viewing area shows the color
and image; they extend into the margins. Note that the default
background color that I set for my browser is quite distinct from the
background color specified in my CSS.
The W3C CSS1 specification states in Section 1.3:
"To set a "default" style property for a document, one can set the
property on an element from which all visible elements descend. In HTML
documents, the 'BODY' element can serve this function".
Thus, properties set for BODY apply to the entire viewing window and not
merely to the area within the margins.
Interesting. That's CSS1 which is very out-of-date of course. CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
For HTML documents whose root HTML element has computed values of
'transparent' for 'background-color' and 'none' for
'background-image', user agents must instead use the computed value
of those properties from that HTML element's first BODY element
child when painting backgrounds for the canvas, and must not paint a
background for that BODY element.
[Which is why your test works in SeaMoney 1.1.11 as it should]
To the OP: the point is not that there's anything wrong with setting a
background on the canvas, if that's what you want. The question is just
how to get it there. You can either set it on the html element, or on
the body element provided you leave the html element with its initial
value for background. The spec recommends the latter for HTML (as
opposed to XHTML) documents. But also check it actually works in the
browsers you're interested in.
In article <sl*********************@bowser.marioworld>,
Ben C <sp******@spam.eggswrote:
CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY? You have no choice
but to instruct HTML (which you know will then be appropriated by
CANVAS)? Is anything said about this?
For HTML documents whose root HTML element has computed values of
'transparent' for 'background-color' and 'none' for
'background-image', user agents must instead use the computed value
of those properties from that HTML element's first BODY element
child when painting backgrounds for the canvas, and must not paint a
background for that BODY element.
--
dorayme
On 2008-08-20, dorayme <do************@optusnet.com.auwrote:
In article <sl*********************@bowser.marioworld>,
Ben C <sp******@spam.eggswrote:
>CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here: http://www.w3.org/TR/CSS21/colors.html#background
14.2.
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
In article <sl*********************@bowser.marioworld>,
Ben C <sp******@spam.eggswrote:
On 2008-08-20, dorayme <do************@optusnet.com.auwrote:
In article <sl*********************@bowser.marioworld>,
Ben C <sp******@spam.eggswrote:
CSS 2.1
....
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here:
http://www.w3.org/TR/CSS21/colors.html#background
14.2.
If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
Yes, the practical is not any big problem, the idea I have is that the
author obviously should do the most with the least. And if you can do as
much as possible with elements you *have* to have (like HTML and BODY),
then, naturally, is it not tempting to give it a go? Here is something
fairly ecoomical (my editor says it was fine without any child in BODY,
so too did iCab but the validator at http://validator.w3.org/ kept
insisting there was something wrong with BODY and implied it might need
a child so I gave it one (reluctantly): http://tinyurl.com/67wd7l
or http://netweaver.com.au/rootStudies/...yElements.html
These are economy.
--
dorayme
Ben C wrote:
>
dorayme wrote:
>>Ben C wrote:
>>CSS 2.1
says:
The background of the root element becomes the background of the
canvas and covers the entire canvas [...]
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element.
[That's what David Karr is thinking of-- CSS 2.1 doesn't say why
they recommend this though, perhaps compatibility with older
browsers?]
I find it hard to imagine the exact context in which the words "For HTML
documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element" is said
(beyond the obvious of them being where they are in CSS 2.1)
They mean as opposed to XHTML. The context is here:
http://www.w3.org/TR/CSS21/colors.html#background
14.2 The background
Authors may specify the background of an element (i.e.,
its rendering surface) as either a color or an image.
In terms of the box model, "background" refers to the
background of the content, padding and border areas.
Border colors and styles are set with the border
properties. Margins are always transparent.
Background properties are not inherited, but the
parent box's background will shine through by
default because of the initial 'transparent'
value on 'background-color'.
The background of the root element becomes the
background of the canvas and covers the entire
canvas, anchored (for 'background-position') at
the same point as it would be if it was painted
only for the root element itself. The root
element does not paint this background again.
For HTML documents, however, we recommend that
authors specify the background for the BODY
element rather than the HTML element. For HTML
documents whose root HTML element has computed
values of 'transparent' for 'background-color'
and 'none' for 'background-image', user agents
must instead use the computed value of those
properties from that HTML element's first BODY
element child when painting backgrounds for
the canvas, and must not paint a background
for that BODY element. Such backgrounds must
also be anchored at the same point as they
would be if they were painted only for the
root element. This does not apply to XHTML
documents.
>
>If the recommendation is on the assumption that you are going to choose
*one* of BODY or HTML to put a background colour on in the knowledge
that it will be appropriated by CANVAS, then BODY for background seems
to be the one favoured. For reasons we can speculate on (you give one
interesting possibility).
That seems to be what they are saying.
>But we need really to know what the reason is and if it bears on the
question of the possibility that the assumption is not always true. What
if you want CANVAS to be a different colour to BODY?
Well exactly. A similar situation exists with overflow-- you can't apply
overflow to the root element, because it always gets moved to the
viewport as I was explaining to Korpela recently.
But it's not a big problem in practice because you usually want overflow
on the viewport, not on the root element.
>You have no choice but to instruct HTML (which you know will then be
appropriated by CANVAS)? Is anything said about this?
Only what you see in 14.2. I guess if you want more backgrounds, you
just nest a couple of DIVs inside BODY.
Interesting discussion about this topic here: http://www.molly.com/2005/02/18/root-element-html/
And a somewhat related IE hack here: http://tagsoup.com/cookbook/css/fixed/
My question is this: what if I simply use identical CSS
settings for *, HTML and BODY? Would that be a reliable
way to style everything (canvas, viewport, etc.) in all
browsers? Other than making the CSS bigger than it needs
to be, is there any downside? Or would * alone be enough?
--
Guy Macon
<http://www.GuyMacon.com/>
On 8/20/2008 5:10 AM, Guy Macon wrote:
Details on CSS changes for IE7
http://blogs.msdn.com/ie/archive/2006/08/22/712830.aspx
http://msdn.microsoft.com/en-us/library/bb250496.aspx
Cascading Style Sheet Compatibility in Internet Explorer 7
I don't have IE7 installed; could someone test the page at
http://www.phaf.org/testroot/root.html and see if IE7
displays it the wau FireFox does?
SeaMonkey 1.1.x uses the same rendering engine as Firefox 2.0.x.
Comparing SeaMonkey 1.1.11 with IE 7.0, I see the following differences:
1. The "Canned Soup" box in IE is shifted slightly higher and
noticeably leftward relative to where it is in SeaMonkey.
2. At the very top of the page is a red box. The box is significantly
taller in IE than in SeaMonkey; it is wider in SeaMonkey than in IE.
3. The box at the very top contains a bar that is centered within the
box. In IE, the bar is blue. In SeaMonkey, the bar appears black.
No, I don't want to capture screen shots and upload them anyplace.
Note:
My IE 7.0 has inconsistent version numbers. From the menu bar,
selecting [Help About Internet Explorer], I see 7.0.5730.11. Looking
at the properties of iexplore.exe, I see 7.0.6000.16705. The user agent
string is:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
2.0.50727)
There are some inconsistencies with SeaMonkey's versions, too. On the
menu bar, selecting [Help About SeaMonkey] displays the user agent
string under "SeaMonkey 1.1.11":
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16)
Gecko/20080702 SeaMonkey/1.1.11
The properties for seamonkey.exe show three different versions:
file version (at the top of the Properties window) -- 1.8.20080.4680
file version (in the "Other version information" area) -- 1.8.1.16:
2008070216 (this is the version of the Gecko rendering engine and the
year-month-date-hour either Gecko or SeaMonkey was compiled)
product version -- 1.1.11
--
David E. Ross
<http://www.rossde.com/>
Q: What's a President Bush cocktail?
A: Business on the rocks.
David E. Ross wrote:
>
On 8/20/2008 5:10 AM, Guy Macon wrote:
>I don't have IE7 installed; could someone test the page at
http://www.phaf.org/testroot/root.html and see if IE7
displays it the wau FireFox does?
SeaMonkey 1.1.x uses the same rendering engine as Firefox 2.0.x.
Comparing SeaMonkey 1.1.11 with IE 7.0, I see the following differences:
1. The "Canned Soup" box in IE is shifted slightly higher and
noticeably leftward relative to where it is in SeaMonkey.
2. At the very top of the page is a red box. The box is significantly
taller in IE than in SeaMonkey; it is wider in SeaMonkey than in IE.
3. The box at the very top contains a bar that is centered within the
box. In IE, the bar is blue. In SeaMonkey, the bar appears black.
>From the menu bar, selecting [Help About Internet Explorer],
I see 7.0.5730.11.
>On the menu bar, selecting [Help About SeaMonkey] displays
[...] SeaMonkey 1.1.11"
Using the same Help About versioning, testing with Internet
Explorer 6.0.2800.1106 and with Mozilla Firefox 2.0.0.16 running
under Windows 2000 Advanced Server (all updates installed) I see:
The "Canned Soup" box in IE is shifted noticeably higher and
noticeably leftward relative to where it is in FireFox.
There is a red box that enclosed a black box with a blue interior
in FireFox. The black box is as high as the red box, but not as
wide.
The red box encloses the entire page -- including a grayed-out
vertical scrollbar -- in IE. FireFox has no scrollbar, and has
a thin white stripe on the left.
The black box has zero height in IE, so I can't tell it it as a
blue interior. I believe that this is the same as what you describe
above.
--
Guy Macon
<http://www.GuyMacon.com/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: mydejamail |
last post by:
Coming from an objectpascal background with strict type checking, I am
being driven nuts by PHP.
Stuff like using variables without declaring them, case sensitivity of
variables, getting true,...
|
by: p s |
last post by:
hi
can someone tell me how to ensure the height of my window is always exact?
(excluding titlebar) in VB6
e.g. if i set the form to 300 pixels, then the total height of the form
takes into...
|
by: Dave |
last post by:
Hello NG,
Why would one not just always use std::multiset<> instead of std::set<> (and
similarly for maps)? Clearly, there must be tradeoffs to gain the ability
to have repeated keys. What are...
|
by: MLH |
last post by:
A form named frmVehicleEntryForm has a number of textbox
controls who's OnGotFocus property setting is an expression...
=Change2Green()
Change2Green() looks something like this...
Dim MyControl...
|
by: DexHex |
last post by:
Hi,
I am stumpt. Is there anyway to set the background image on a webpart
title?
|
by: PeterKellner |
last post by:
I'm having trouble setting a background style in a master page. The
declaration in the master page looks like this:
<div id="header_image" runat="server" style="background: transparent...
|
by: vijai.kalyan |
last post by:
Hello,
I wrote a trivial program to set the console title in a console
application. Here is the code:-
namespace myns
{
class SetTitle
{
static void Main ( string args )
|
by: Mike.Wolowicz |
last post by:
I have a report that changes background colour when a running total
field hits a certain value...
Private Sub Detail_Format(Cancel As Integer, FormatCount As Integer)
If >= 2400001 Then...
|
by: jaybob217 |
last post by:
Is there a way to set a labels background image programatically from the code behind page? I've played around with "style background-image: url()" but can't seem to get it to work.
Label.Style
|
by: RKT |
last post by:
I have a DataGridView bound to an MS Access table. This is a single-
user application. When the User is adding or editing a row, the User
may click on a Control elsewhere. That Control has context...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
