473,325 Members | 2,872 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

Onmouseover, onmouseout question

I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/
I'm working on this website and have it half done:
www.mygiftbasketideas.com - I also what the table to change color on
mouseover - this is the code I am using so far:

in the script.js
if (document.images)
{
image2= new Image(100,100);
image2.src="/store/images/P/romance.jpg";
image3= new Image(100,100);
image3.src="/store/images/P/welcome_baby_boy.jpg";
image4= new Image(100,100);
image4.src="/store/images/P/picnic.jpg";
image5= new Image(100,100);
image5.src="/store/images/P/vineyard.jpg";
image6= new Image(100,100);
image6.src="/store/images/P/european.jpg";
image7= new Image(100,100);
image7.src="/store/images/P/lasting.jpg";
image8= new Image(100,100);
image8.src="/store/images/P/birthday_celebrate.jpg";
image9= new Image(100,100);
image9.src="/store/images/P/patriotic.jpg";
image10= new Image(100,100);
image10.src="/store/images/P/tea.jpg";
image11= new Image(100,100);
image11.src="/store/images/P/thanks.jpg";
image12= new Image(100,100);
image12.src="/store/images/P/spa_pleasure.jpg";
}

function change1(picName,imgName)
{
if (document.images)
{
imgOn=eval(imgName + ".src");
document[picName].src= imgOn;
}
}

imgOn=eval(imgName + ".src");
document[picName].src= imgOn;
then on the HTML page:
<table width="600" border="1" bordercolor="#993333" cellspacing="0"
cellpadding="00">
<tr>
<th scope="col" align="left"><A href="#"><IMG alt=""
src="{$ImagesDir}/romance.jpg" name="pic1" border=0></A></th>
<th scope="col" valign="top">
<table height="100%" width="200" cellspacing="0" cellpadding="0"
border="1" background="/store/skin1/images/BACKGROUND.jpg"
bordercolor="#993333">
<tr><td width="200" height="30" align="left"><A
onMouseover="change1('pic1','image2')"
onMouseout="change1('pic1','image2')" title="Valentine Gifts"
rel="nofollow" href="/Valentine-gift-basket.html">
<div class="menu_text">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Va lentine
Gifts</div>
</A></td></tr>...........

How do I do both?
Thanks in advance
Lisa

Jan 16 '07 #1
9 1835
peashoe wrote:
I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/
I'm working on this website and have it half done:
www.mygiftbasketideas.com - I also what the table to change color on
mouseover - this is the code I am using so far:
[snip code]
How do I do both?
This demonstrates the principle:

<!-- BEGIN -->
<script type="text/javascript">
linkimg_over = new Image();
linkimg_over.src =
'http://www.myweddingfavors.com/images/core/bridalBtn-over.gif';
linkimg_out = new Image();
linkimg_out.src =
'http://www.myweddingfavors.com/images/core/bridalBtn.gif';
otherimg_over = new Image();
otherimg_over.src =
'http://www.mygiftbasketideas.com/store/images/P/welcome_baby_boy.jpg';
otherimg_out = new Image();
otherimg_out.src =
'http://www.mygiftbasketideas.com/store/images/P/birthday_celebrate.jpg';

</script>

<a href="#"
onMouseover="
document.getElementById('pic1').src = eval('linkimg_over.src');
document.getElementById('pic2').src = eval('otherimg_over.src');
"
onMouseout="
document.getElementById('pic1').src = eval('linkimg_out.src');
document.getElementById('pic2').src = eval('otherimg_out.src');
">
<img border="0" width="215" height="33" id="pic1"
src="http://www.myweddingfavors.com/images/core/bridalBtn.gif">
</a>
<img id="pic2" border="0" width="400" height="350"
src="http://www.mygiftbasketideas.com/store/images/P/birthday_celebrate.jpg">
<!-- END -->

In order to work around buffering issues, I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">

Hope this helps,

--
Bart

Jan 16 '07 #2
Bart Van der Donck wrote:

[...]
In order to work around buffering issues, I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
Erm, I mean the opposite:

<META HTTP-EQUIV="cache-control" CONTENT="cache">
<META HTTP-EQUIV="expires" content="Sat, 31 Dec 2050 23:59:59 GMT">
<META HTTP-EQUIV="pragma" CONTENT="cache">

--
Bart

Jan 16 '07 #3
Bart Van der Donck wrote:
<snip>
<a href="#"
onMouseover="
document.getElementById('pic1').src = eval('linkimg_over.src');
<snip>

One of the more telling indicators of an - eval - abuse is where the
argument to - eval - is a siring literal (rather than an expression
combining string literals and variables, which is only almost always
an - eval - abuse). There are no circumstances where the contents of
such a string literal argument to - eval - cannot be used to replace the
entire - eval - call. That is:-

eval('linkimg_over.src');

- can _always_ be replaced with:-

linkimg_over.src

- to _precisely_ the same effect (except for being shorter, clearer,
(potentially much) faster, better supported and generally easier to
debug if erroneous).
Why use the general - document.getElementById('pic1') - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more
self-documenting (you know from the source code that an IMG element is
the intended subject of the operation) and potentially much faster
(because of the size difference between the images collection and the
entire document)?
In order to work around buffering issues,
If there are "buffering issues" you should be able to state what they
are (details, cause and effect relationships, symptoms and
consequences). Otherwise you are just suggesting that there is a 'bogy
man' named "buffering issues" out there, waiting to byte those who do
not chant the traditional incantation. That is hardly a rout to
understanding, and certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately rational and
logical.
I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
<snip>

There is nothing that requires (or even implies) that a UA should pay
any attention to <META HTTP_EQUIVelements in mark-up, and there is
good reason to believe that even if a UA does it would not do so in
preference to HTTP headers sent with a resource (and are subject to
detailed specification). Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up, why not
propose the employment of the appropriate HTTP headers?

Richard.
Jan 16 '07 #4
Richard Cornford wrote:
Bart Van der Donck wrote:
<snip>
<a href="#"
onMouseover="
document.getElementById('pic1').src = eval('linkimg_over.src');
<snip>

One of the more telling indicators of an - eval - abuse is where the
argument to - eval - is a siring literal (rather than an expression
combining string literals and variables, which is only almost always
an - eval - abuse). There are no circumstances where the contents of
such a string literal argument to - eval - cannot be used to replace the
entire - eval - call. That is:-

eval('linkimg_over.src');

- can _always_ be replaced with:-

linkimg_over.src

- to _precisely_ the same effect (except for being shorter, clearer,
(potentially much) faster, better supported and generally easier to
debug if erroneous).
Then that is a better practice indeed.
Why use the general - document.getElementById('pic1') - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more
self-documenting (you know from the source code that an IMG element is
the intended subject of the operation) and potentially much faster
(because of the size difference between the images collection and the
entire document)?
I'ld say this is more a matter of preference of the coder.
In order to work around buffering issues,

If there are "buffering issues" you should be able to state what they
are (details, cause and effect relationships, symptoms and
consequences). Otherwise you are just suggesting that there is a 'bogy
man' named "buffering issues" out there, waiting to byte those who do
not chant the traditional incantation. That is hardly a rout to
understanding, and certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately rational and
logical.
I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
<snip>

There is nothing that requires (or even implies) that a UA should pay
any attention to <META HTTP_EQUIVelements in mark-up, and there is
good reason to believe that even if a UA does it would not do so in
preference to HTTP headers sent with a resource (and are subject to
detailed specification). Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up, why not
propose the employment of the appropriate HTTP headers?
I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would exist.

Let me tell you why I counseled the use of those META headers. About
two/three years ago I used such image preloading techniques in a
geo-application. It worked well, but it appeared that in Microsoft
Internet Explorer (I think 5.x at that time) the image buffer could be
flushed sometimes so that the browser needed to fetch the image(s) back
from server. It didn't happen too often though, but it did, and I had a
feeling at that time that it had something to do with the code
complexity of that project as well. Since I added the META-tags, the
images were cached correctly and were always shown immediately.

For me that was reason enough to start using them ever since for this
kind of image preloading.

--
Bart

Jan 16 '07 #5
Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
<snip>
<a href="#"
onMouseover="
document.getElementById('pic1').src = eval('linkimg_over.src');
<snip>

One of the more telling indicators of an - eval - abuse is where
the argument to - eval - is a siring literal (rather than an
expression combining string literals and variables, which is
only almost always an - eval - abuse). There are no circumstances
where the contents of such a string literal argument to - eval -
cannot be used to replace the entire - eval - call. That is:-

eval('linkimg_over.src');

- can _always_ be replaced with:-

linkimg_over.src

- to _precisely_ the same effect (except for being shorter,
clearer, (potentially much) faster, better supported and
generally easier to debug if erroneous).

Then that is a better practice indeed.
>Why use the general - document.getElementById('pic1') - to
reference an IMG element when the DOM standard -
document.images['pic1'] - is more self-documenting (you
know from the source code that an IMG element is the
intended subject of the operation) and potentially
much faster (because of the size difference between the
images collection and the entire document)?

I'ld say this is more a matter of preference of the coder.
And using - eval - on a single string literal is not just a matter of
preference?

There are 4 reasons for using - doucment.images - to reference IMG
elements:-

1. It is HTML DOM standard (which is an applicable standard
in an environment where you are referencing (x)HTML IMG
elements.
2. It is back compatible (even referencing by ID attribute
instead of by NAME attribute you have included IE 4 at
zero additional coding effort).
3. It is self-documenting (you know the subject is going to
be an IMG element).
4. It is potentially fastest (as the browser has pre-assembled
a collection of all IMG elements on the page)

While arguments in favour of using - getElementById - in its place are
restricted to:-

1. It is Core DOM standard.

Is it really personal preference that would have someone use the latter
over the former, or something else?
>>In order to work around buffering issues,

If there are "buffering issues" you should be able to state
what they are (details, cause and effect relationships,
symptoms and consequences). Otherwise you are just suggesting
that there is a 'bogy man' named "buffering issues" out there,
waiting to byte those who do not chant the traditional
incantation. That is hardly a rout to understanding, and
certainly not a rout to taking informed control over
achieving a desired outcome in a system that is ultimately
rational and logical.
>>I suggest to add the
following in your page's header section:

<META HTTP-EQUIV="pragma" CONTENT="no-cache">
<META HTTP-EQUIV="expires" CONTENT="-1">
<META HTTP-EQUIV="cache-control" CONTENT="no-cache">
<snip>

There is nothing that requires (or even implies) that a UA
should pay any attention to <META HTTP_EQUIVelements in
mark-up, and there is good reason to believe that even if
a UA does it would not do so in preference to HTTP headers
sent with a resource (and are subject to detailed
specification). Rather than propose the cargo-cult/mystical
inaction formulation of using META elements in the mark-up,
why not propose the employment of the appropriate HTTP
headers?

I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would
exist.
You don't think the HTTP pragam, expires and cache-control headers might
come into this then? Do you actually appreciate what HTTP-EQUIV is
supposed to mean in a META element (what aspect of HTTP the EQUIV is
'equivalent' to)?
Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes
What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?
so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.
The HTTP headers sent with the images are much more likely to influence
the frequency with which the browser sees the need to query the server
for updates. From what I am reading I suspect that never knew what those
headers were (and possible never knew they existed).
Since I added the META-tags, the images were cached
correctly and were always shown immediately.
So you observed a coincidence, but never established a cause and effect
relationship.
For me that was reason enough to start using them ever
since for this kind of image preloading.
That is "programming by coincidence", and so not something you should be
recommending to others. Most of the META tag cargo-cults have started
that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
....".)

Richard.
Jan 16 '07 #6
dd

Bart Van der Donck wrote:
Why use the general - document.getElementById('pic1') - to reference an
IMG element when the DOM standard - document.images['pic1'] - is more

I'ld say this is more a matter of preference of the coder.
True, it is a preference of the coder, but it's somewhat
inefficient to "ask" the browser to find something by looking
through the whole DOM, when it can already restrict the
search to the images array instead.

It's equally inefficient to do getElementsByTagName('iframe')
when document.frames[] gives you the same thing.

~dd

Jan 17 '07 #7
dd

peashoe wrote:
I need to create a javascript that not only changes a picture, but also
the link: here is an example of what I need www.myweddingfavors.com/
There's an array built for you by the browser called
document.links. You can manipulate the links objects
to change the target:

document.links[i].target = some_alt_target;

If you use an onmouseover event and call a function to
do the change, you can reference the link object using
the this keyword ( this.target ).

~dd

Jan 17 '07 #8
Richard Cornford wrote:
Bart Van der Donck wrote:
I am not aware of an HTTP header that affects image preloading
techniques from javascript, and I'ld be surprised if this would
exist.

You don't think the HTTP pragam, expires and cache-control headers might
come into this then? Do you actually appreciate what HTTP-EQUIV is
supposed to mean in a META element (what aspect of HTTP the EQUIV is
'equivalent' to)?
The actual HTTP-headers are more important, yes. HTTP-EQUIV might help
here or there and it certanly doesn't harm to repeat an HTTP header in
HTTP-EQUIV. It's right that 'equivalent' is too much honour for these
tags.
Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes

What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?
I'm not sure about the exact distinction between those two. Just the
images that were preloaded, stored in buffer and available for
(immediate) referencing on the page.
so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.

The HTTP headers sent with the images are much more likely to influence
the frequency with which the browser sees the need to query the server
for updates. From what I am reading I suspect that never knew what those
headers were (and possible never knew they existed).
Then tell me, does javascript read out the image's HTTP headers in
order to decide when it should flush the (preloaded) image ? I would be
surprised if that were true.

Working with such stuff seems very browser dependent and very dangerous
to rely on. But yes, there is technically no problem at server side.
Since I added the META-tags, the images were cached
correctly and were always shown immediately.

So you observed a coincidence, but never established a cause and effect
relationship.
That is true up to a certain point. I tested my solution thoroughly and
I concluded that it worked okay (which it still does until today, btw).
I'm not sure how things work from your Sedes Sapientiae, but I have
less-than-perfect expierences as well.
For me that was reason enough to start using them ever
since for this kind of image preloading.

That is "programming by coincidence", and so not something you should be
recommending to others. Most of the META tag cargo-cults have started
that way (all praise the mighty HTTP-EQUIV; "META, META, Meta, meta,
...".)
It's not programming by coincidence, but a practical solution to a
concrete problem.

--
Bart

Jan 17 '07 #9
Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
>>I am not aware of an HTTP header that affects image
preloading techniques from javascript, and I'ld be
surprised if this would exist.

You don't think the HTTP pragam, expires and cache-control
headers might come into this then? Do you actually appreciate
what HTTP-EQUIV is supposed to mean in a META element (what
aspect of HTTP the EQUIV is 'equivalent' to)?

The actual HTTP-headers are more important, yes. HTTP-EQUIV
might help here or there
"Might help here or there"? Are we working with technology or offering
prayers and sacrifices for a good harvest?
and it certanly doesn't harm to repeat an HTTP header in
HTTP-EQUIV.
Web development is plagued with things that 'do no harm'. It should be
important to distinguish between the things that do some good and the things
that are no more that mystical incantations, and possibly the things that
were once of some value but have not become redundant (and are continued
because they are doing no harm so nothing exists to break the habit).

An example of the latter is wrapping SCRIPT element contents in <!--
.... -->, which, for a short period, was a good idea, but is now totally
redundant but persist because it is (mostly) harmless. Unfortunately the way
in which it persist is in people who operate on the basis of mystical
incantation propose to others that this incantation is necessary when
'conjuring' a SCRIPT element.
It's right that 'equivalent' is too much honour for these
tags.
Absolutly.
>>Let me tell you why I counseled the use of those META headers.
About two/three years ago I used such image preloading
techniques in a geo-application. It worked well, but it
appeared that in Microsoft Internet Explorer (I think 5.x
at that time) the image buffer could be flushed sometimes

What is the "image buffer"? Are you talking about the browser's
client-side cache, or images in a running browser's memory?

I'm not sure about the exact distinction between those two.
Just the images that were preloaded, stored in buffer and
available for (immediate) referencing on the page.
The process that is labelled "preloading" is more a matter of pre-requesting
an image, with the intention of moving it into the browser's local disc
cache. The cachablitly of that image has a considerable impact on the
usefulness of doing that.
>>so that the browser needed to fetch the image(s)
back from server. It didn't happen too often though, but
it did, and I had a feeling at that time that it had
something to do with the code complexity of that project
as well.

The HTTP headers sent with the images are much more likely to
influence the frequency with which the browser sees the need to
query the server for updates. From what I am reading I suspect that
never knew what those headers were (and possible never knew they
existed).

Then tell me, does javascript read out the image's HTTP headers
in order to decide when it should flush the (preloaded) image ?
I would be surprised if that were true.
Javascript has no role in the decision as to whether an image is cached,
used from the cache or re-loaded from the server. The browser makes that
decision, but it certainly is considerably influenced in that decision which
headers are sent with an image (or with the image last time it as requested,
or instead of the image (in the case of a response to a 'If-Modified-Since"
request where the server sees no update)).
Working with such stuff seems very browser dependent
and very dangerous to rely on.
However something is "worked with", a starting position of understanding
what HTTP provided for use in relation to caching would be of considerably
value in determining how any browser may act outside of the specified
behaviour (or fill in any 'gaps').
But yes, there is technically no problem at
server side.
>>Since I added the META-tags, the images were cached
correctly and were always shown immediately.

So you observed a coincidence, but never established a
cause and effect relationship.

That is true up to a certain point.
You either establish a cause and effect relationship or you don't. There is
no "up to a certain point" in that.
I tested my solution thoroughly and I concluded that it
worked okay (which it still does until today, btw).
If your 'solution' was a coincidence (and the theory says it will have been
as there is no reason to expect the cachability of an HTML page (assuming
that the HTTP-EQUIVE META elements on the page will effect its cachablity
(though they can do no more)) would influence the caching behaviour of image
resources that are referenced from the page) but was in itself harmless then
its repeated use ("tested ... thoroughly") would demonstrate nothing.
I'm not sure how things work from your Sedes Sapientiae,
but I have less-than-perfect expierences as well.
Is that another bogeyman named "less-than-perfect expierences"?
>>For me that was reason enough to start using them ever
since for this kind of image preloading.

That is "programming by coincidence", and so not something
you should be recommending to others. Most of the META tag
cargo-cults have started that way (all praise the mighty
HTTP-EQUIV; "META, META, Meta, meta, ...".)

It's not programming by coincidence,
Demonstrate the cause and effect relationships and it may not be. But it
looks to me as if you never even considered many of the factors that would
be expected to influence the situation.
but a practical solution to a concrete problem.
You do not even know for certain that it influenced the situation you
described, let alone that it 'solved' anything. The most you are able to say
it that it was not harmful.

Richard.

Jan 20 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Tim | last post by:
Hope someone in the big wide world can help... What I want to do is have an image slideshow which automatically scrolls through a series of images very fast, then pauses when you move your mouse...
1
by: christian9997 | last post by:
Hi I was trying to create a page where a SubMenu would appear when the user moved the mouse over an item of a Menu (= Table Cell <TD>). Unfortunately there seems to be a problem; the onMouseOver...
4
by: laurie | last post by:
Hi. I have a DIV section that has many thumbnail images inside it. I have a DIV so all images can fit in a row and the horizontal scroll bar is used to move the thumbnails from left to right. ...
7
by: Richard | last post by:
I know I can have like <a href="#" onclick="dothis" onmouseover="dothat"> But how do you properly code two mouseover's in one statement? <a href="#" onmousever="dothis" onmouseover="dothat"> As...
3
by: Rob Roberts | last post by:
I'm using .NET 2.0 and C# on a web site, and I'm trying to use the onmouseover and onmouseout events to do a rollover effect on an asp.net button. I've tried manually adding the events to the...
2
by: MrCode2k | last post by:
Hello, Trying to do: I just want a table that I can scroll and that has fixed headers. Problem: I got it to work but when I added the onmouseover event it didn't work anymore....
7
by: MrCode2k | last post by:
Hello, Trying to do: I just want a table that I can scroll and that has fixed headers. Problem: I got it to work but when I added the onmouseover event it didn't work anymore....
3
by: oopaevah | last post by:
I have written some dom code to create a list of divs, each with it's own id. I want to set the onmouseover and onmouseout events to highlight the div when the mouse is over it. However I cannot...
2
by: Daz | last post by:
Hi everyone. I think my problem is a simple one, but I am completely baffled as to how to pull it off. I have a piece of code like so... document.write( "<img id=\"slideshow_toggle\"...
4
by: bgold12 | last post by:
Hey, I have kind of a weird problem. I have a span that I'm intentionally overflowing a table cell (<td>), so that it stretches over the table cells to the right of the parent table cell. I want...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.