Hi All,
I have a tiny program:
<!doctype HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>MyTitl e</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1"/>
</head>
<body>
<?php
$host = $_SERVER['HTTP_HOST'];
$server = strtolower($hos t);
echo 'My variables<bg>';
echo("<br>Host: $host");
echo("<br>Serve r: $server");
?>
</body>
</html>
I upload it to my webserver as test.html and as test.php. Then I test
them in my webbrowser. The test.html does not work, but the test.php
does. Can someone tell me why?
Very confused
Lennart Björk
Jan 25 '06
59  7038 
d wrote: I don't want .php files on the end of my files, because when the user
gets them, they don't have any PHP in them. That .PHP is there for my
benefit, not theirs, which is unwanted.
Here's a hint - they couldn't give a rat's ass what the extension is. FTP requests are not HTTP.
So what? Should all files that are ftp'ed have a .ftp extension?!? When your browser gets files from ftp://, it's not a web browser any
more but an FTP client.
No it's still a web browser, doing ftp protocol. I said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk. I never said the server should parse MP3 files or whatever, as I'm not
generating them dynamically.
What does it matter if you are doing it dynamically or not? When I do generate them, I can still have PHP providing them, AND keep
the .mp3 as an extension, because of the tools I use on my site. By
your logic, if you have a dynamically-generated MP3 on your site, it
should end in .php. That's not particularly cool, is it?
Cool?!? I'm not the one who has this fetch with file extensions. I could
care less if it says .txt or if it's dynamic - it's *you* who cares
about these things. My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps. It's not wasteful.
How could it not be? You do understand how computers work don't you? You
do understand that extra processing is indeed happening. You do
understand that under large numbers of accesses such small differences
in processing time add up don't you?!? It's a more than reasonable trade-off for having a decent site, with
tidy URLs.
Again, you have this fetish with file extensions in URLs. Nobody else
cares! And to me a .php extension is a little "tidier" than .html - hell
it's one less character! :-) You wouldn't want your design sloppy,
I don't find it sloppy. Indeed I find it very logical. so why your URLs? The site is a whole - asking someone to ignore the
mess in the address bar because "it's just the way the web server
works" is a bit silly. It's supposed to work for you, not the other
way round :)
Again, nobody cares about what characters are in the URL. If they did
they'd start screaming about the silly http:'s and the &parm=<long assed
string of junk characters> and the like. The .php or .html at the end is
one of the least things to be concerned about!
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
It may be by design, but that doesn't mean it's necessarily good.
In this case it does.
I still don't see how you can qualify that. I mean, the file doesn't contain php when the client gets it, so why should it be named .php?
Surely a dynamic web server should appear exactly the same as a static one - all files that contain HTML when viewed should be called ..html.
Again, why? Who cares (besides you)?
Because the server is serving up HTML, not PHP.
If you want them called any number of things, then be my guest. I just happen to think presentation matters.
Let's us know when you're done writing your great web server! :-(
I don't have to. It's called apache, and it does the trick perfectly.
As for performance, the numbers are easy to compute. If you know how, say, the PHP apache module works, you'll see that the hit is absolutely, positively minimal.
A 1/2 cent rise in the sales tax is also minimal - when looked at under a microscope! However such things raise millions of dollars!
We're talking 0.04, not 0.5 :)
If it was otherwise, the inherent overhead of processing dynamic PHP files would stop people from using PHP on any old webserver.
This argument holds no water whatsoever. PHP files will be processed with PHP. The issue I was talking about is making each and every file go through parsing even when no PHP is present.
I said just put .html files through, not every single file.
My scheme doesn't prevent anyone from using more than one technology. It's not as if extensions are the only way of determining what's in a file.
Then you must make the httpd process overly complicated be having it have to figure out, each and every time, any of a possibly myriad of possible web scripting technologies.
Incorrect. As I said, the httpd process doesn't have to be overly complicated. There extension is not the only way to determine what's in a file.
Your points aren't exactly showstoppers.
And your one point is one of pure aesthetics!
Exactly.
If you're confused by having php in html files,
Who ever said that! I'm not stupid!
You said it was complex to have a web server configured this way. It really isn't.
you probably shouldn't be anywhere near a computer in case you look at it funny and choke yourself to death.
And you're the one getting bent out of shape because a file says .php instead of .html. Who's confused here? (Hint: You are!)
How is that being confused?? I just want files named to reflect what's in them. You wouldn't want your html files called .jpg, would you?
And as I said earlier, it doesn't stop anyone from using multiple technologies at once,
Yes but it adds unnecessary complications and processing time based on a whim that only you have!
No complications what so ever. The extra processing time, as I have demonstrated is nothing. My tests showed that sometimes it's even quicker to do it this way, which means that there are other factors that play a much bigger part in performance, much more than parsing .html files.
and if a web server struggles because it has to check html files for php when there necessarily isn't any,
It's not a struggle - it's a waste of time! Do you understand the definition of the word efficient?!?
If you think presentation is a waste of time, then fine - I can't convince you otherwise. Efficiency doesn't necessarily mean you end up with the best product.
then it's not going to be very good at running any complex php, as that requires a LOT more work then just checking for "<?php" in a file.
Again, it's unnecessary work. You can't seem to understand that simple concept.
I've demonstrated the "unnecessar y work" is absolutely, positively nothing.
Just because it's the "done thing" doesn't automatically make it the best thing.
Again, in this case it does. If not then make your own web server and see who else in the planet is interested in such "technology ". But don't quite your day gig!
Can you qualify these assertions. I've done tests, and I've seen that the performance hit is nothing. I don't have to make my own web server. Apache was built to do just these things. The reason PHP moved from CGI to a native apache module was for exactly this kind of thing. If you don't understand the technology, then perhaps you shouldn't quit your day job :)
If you don't want to take pride in your work and have messy URLs with weird extensions that don't match the content and query strings unreadable to humans stretching from here to the moon, then be my guest.
I measure my work by the quality of the content of the page itself - not it's URL. To me, and everybody else in the world except apparently you, I don't find .php as a weird extension (perhaps because I understand it) nor as any more messier than .html. It's you that have a fetish with that - not I.
I measure my work by the user experience. I don't want any dirty laundry out in the open. I want complete control over every aesthetic, from the quality of the HTML to the quality of the addressing. I find ..php a weird extension because the files don't contain a single shred of php when the user gets them. And, after all, websites are about the user, not the sysadmin or the developer.
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
Here are some tests I did:
I created two virtualhosts in apache. One parses .php files, one parses both .php and .html. I filled it with 150 html documents (from the apache manual), and wrote a script to download each file from each server.
The results:
They're identical. Sometimes the HTML site is faster by 0.002s, sometimes it's slower by the same. So, it's pretty fair to say, that Apache and PHP don't give a damn if they're parsing HTML files for PHP, as as I said, the performance hit is minimal. In fact, there seems to be NO performance hit. In fact, variations of the computer's stress played a far, far greater role in determining the speed of parsing than the apache setup. So, to summarise, whether your PHP module is parsing HTML files with no PHP in them is the least of your worries.
You did a whopping 150 files. Oh my god! How did your poor little server put up with all that processing???
So you come up with a better test, sunshine. You asked me to do research, I did. I gave you figures, and suddenly they're not good enough for you. And, in case you didn't notice, I did 150 files to give a 150x demonstration of the difference in required processing, not to represent the average load of the server. Even someone with a basic grasp of statistics could see that. I never claimed I was representing your average webserver's daily load.
How many hits does Google get a day? An hour? I don't think they are even approaching that whopping 150 hits!
BTW: Things deteriorate over time and side of files too as the server can grow to taking up more and more resources over time.
So I see you haven't written code for anything approaching massive sites, if you claim that. Thanks.
"Michael Winter" <m.******@bluey onder.co.uk> wrote in message
news:D2******** *****@text.news .blueyonder.co. uk... On 26/01/2006 17:43, d wrote:
Where to begin.
It would be nice if you started by not top-posting, but I don't think
that's a requirement of this particular group.
I don't want .php files on the end of my files, because when the user
gets them, they don't have any PHP in them.
Given that the average user isn't really aware of what HTML is, I wouldn't
say that that was much of a reason to reconfigure a server in the way
you'd like.
I don't code sites for just your average user. If you're selling your
company, or indeed a product, to people who know, then things like this
speak very highly of the attention you pay to your work. It's like making a
great watch, then using bits of old band-aids for a strap.
That .PHP is there for my benefit, not theirs, which is unwanted.
If you were really concerned about this, wouldn't the best solution be to
remove 'extensions' from URLs entirely? If you want to relieve the user of
this 'burden', then hiding the mechanics should be the ultimate goal.
Now you have it :) I moved from the .html-only set-up to my own site
engine, which does indeed do away with extensions altogether.
[snip]
My tests have shown, to me at least, that the performance hit is a
myth.
Perhaps, but you haven't actually stated what these tests specifically
entailed so no-one else can perform them and reproduce your results, or
even judge how relevant the tests are to their own circumstances.
I did. I hit two identical servers, one set to parse html via php, and one
not, repeatedly with sets of 150 requests (not just once, but many times in
a row), and recorded the times. The times fluctuated between the
html-parsing server being quicker, and the non-html-parsing server being
quicker.
[...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs.
A decent site is determined by many things, but URLs have a relatively low
priority (usability and content clearly come first). Length and the extent
to which they can be remembered and transcribed are the most important
factors and 'extensions' don't impact any of these significantly at all.
But once you have code great HTML, great CSS, great PHP, and you server is
quick, smooth and working well, it doesn't make sense to just stop making
your site better. I won't stop until my site is as perfect as possible. My
site engine uses ONLY human-readable urls. No digits, no ridiculous query
strings (in fact no query strings at all), and all can be interpreted and
even re-written by the user if they want.
[snip]
Mike
dave
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
"Andrew DeFaria" <An****@DeFaria .com> wrote in message news:43******** *************** @news.sonic.net ...
d wrote:
I don't want .php files on the end of my files, because when the user gets them, they don't have any PHP in them. That .PHP is there for my benefit, not theirs, which is unwanted.
Here's a hint - they couldn't give a rat's ass what the extension is.
Not everyone, but some people. And if you cater for those people, it suddenly gets very important.
FTP requests are not HTTP.
So what? Should all files that are ftp'ed have a .ftp extension?!?
We are talking about web servers, not FTP servers. I thought you would understand that.
When your browser gets files from ftp://, it's not a web browser any more but an FTP client.
No it's still a web browser, doing ftp protocol.
FTP is not part of the web. It's part of the internet, but not part of the web. Again, I thought you would understand that.
I said pissing match, not pissing.
A pissing match starts when somebody starts pissing junk.
Fantastic. Really great work.
I never said the server should parse MP3 files or whatever, as I'm not generating them dynamically.
What does it matter if you are doing it dynamically or not?
Apparently it does to you - as you want your dynamically-generated content to be called .php, as that's how it should be "by design".
When I do generate them, I can still have PHP providing them, AND keep the .mp3 as an extension, because of the tools I use on my site. By your logic, if you have a dynamically-generated MP3 on your site, it should end in .php. That's not particularly cool, is it?
Cool?!? I'm not the one who has this fetch with file extensions. I could care less if it says .txt or if it's dynamic - it's you who cares about these things.
It's not a fetish. It's called presentation. Just because you can't care less doesn't mean those visiting your site don't.
My tests have shown, to me at least, that the performance hit is a myth.
For 150 files, perhaps.
Repeatedly, about 50 times.
It's not wasteful.
How could it not be? You do understand how computers work don't you? You do understand that extra processing is indeed happening. You do understand that under large numbers of accesses such small differences in processing time add up don't you?!?
I also know how the PHP module works. I can see that the extra processing is negligable compared to other factors affecting the server. My tests have shown that. If what you say is true, my html test server should have repeatedly out-performed the html-parsing one. It didn't.
It's a more than reasonable trade-off for having a decent site, with tidy URLs.
Again, you have this fetish with file extensions in URLs. Nobody else cares! And to me a .php extension is a little "tidier" than .html - hell it's one less character! :-)
People do care. Just because you don't think so doesn't make them go away. If you're putting the quality of your work up against someone else, and they have taken the small amount of time to make their URLs look human-friendly, then your site won't look as good as theirs. That can lose you contracts.
You wouldn't want your design sloppy,
I don't find it sloppy. Indeed I find it very logical.
Logical from the web server's perspective, not the user's. As websites are coded to make the user happy, not the webserver, that's a pretty poor excuse.
so why your URLs? The site is a whole - asking someone to ignore the mess in the address bar because "it's just the way the web server works" is a bit silly. It's supposed to work for you, not the other way round :)
Again, nobody cares about what characters are in the URL. If they did they'd start screaming about the silly http:'s and the &parm=<long assed string of junk characters> and the like. The .php or .html at the end is one of the least things to be concerned about!
Just saying "but nobody cares" doesn't make them not care. And as for the query string - I agree with you. I don't use query strings. Just because it's least concerning doesn't make it not concerning at all. It's like making a painting and putting it in a crappy frame.
On Fri, 27 Jan 2006 00:52:31 +0000, d wrote: "Michael Winter" <m.******@bluey onder.co.uk> wrote in message
news:D2******** *****@text.news .blueyonder.co. uk... On 26/01/2006 17:43, d wrote:
Where to begin.
It would be nice if you started by not top-posting, but I don't think
that's a requirement of this particular group.
I don't want .php files on the end of my files, because when the user
gets them, they don't have any PHP in them.
Given that the average user isn't really aware of what HTML is, I wouldn't
say that that was much of a reason to reconfigure a server in the way
you'd like.
I don't code sites for just your average user. If you're selling your
company, or indeed a product, to people who know, then things like this
speak very highly of the attention you pay to your work. It's like making a
great watch, then using bits of old band-aids for a strap.
Don't know who you code for, but quality begins with w3c, not
url extensions. That .PHP is there for my benefit, not theirs, which is unwanted.
No, the php extension is there for the web servers benefit. No matter what
you say, parsing every page for the potential existence of code, and then
working out what it is *is* expensive.
The programmers who generated apache decided on this method. They *do*
know more than you about serving web pages. I guarantee it.
If you were really concerned about this, wouldn't the best solution be
to remove 'extensions' from URLs entirely? If you want to relieve the
user of this 'burden', then hiding the mechanics should be the ultimate
goal.
Now you have it :) I moved from the .html-only set-up to my own site
engine, which does indeed do away with extensions altogether.
Non-apache web servers are off-topic for this group.
[snip]
My tests have shown, to me at least, that the performance hit is a
myth.
Perhaps, but you haven't actually stated what these tests specifically
entailed so no-one else can perform them and reproduce your results, or
even judge how relevant the tests are to their own circumstances.
I did. I hit two identical servers, one set to parse html via php, and
one not, repeatedly with sets of 150 requests (not just once, but many
times in a row), and recorded the times. The times fluctuated between
the html-parsing server being quicker, and the non-html-parsing server
being quicker.
150, wow! Lets try actually loading the server, eh? Were the requests
sequential or parallel? How about a real-world test - a couple of thousand
page hits per second should do as a start. [...] It's a more than reasonable trade-off for having a decent site,
with tidy URLs.
Where is this site???
A decent site is determined by many things, but URLs have a relatively
low priority (usability and content clearly come first). Length and the
extent to which they can be remembered and transcribed are the most
important factors and 'extensions' don't impact any of these
significantly at all.
But once you have code great HTML, great CSS, great PHP, and you server
is quick, smooth and working well, it doesn't make sense to just stop
making your site better. I won't stop until my site is as perfect as
possible. My site engine uses ONLY human-readable urls. No digits, no
ridiculous query strings (in fact no query strings at all), and all can
be interpreted and even re-written by the user if they want.
No cookies, no session variables? I don't get why you think that a markup
language designed to be read by a machine should be pretty - in fact for
it to be as efficient as possible it should be as small as possible. So
that's on a single line with no indentation. [snip]
Mike
dave
--
Michael Winter
Prefix subject with [News] before replying by e-mail.
Your presumptions are all wrong. You code for w3c first, then search
engines second.
And you do all you can to protect your server.
Steve
Message-ID: <LY************ ****@text.news. blueyonder.co.u k> from d
contained the following: The same thing a shop front has to do with a shop's interior :) It's part
of your "client-facing presence", and as such represents your company. I
can understand if other people don't feel like it represents them, but as
something of a stickler for details, it's something I notice.
In that case I wouldn't have .php or .html on customer facing stuff.
I'd use directories.
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
Message-ID: <j9************ ****@text.news. blueyonder.co.u k> from d
contained the following: I don't code sites for just your average user. If you're selling your
company, or indeed a product, to people who know, then things like this
speak very highly of the attention you pay to your work. It's like making a
great watch, then using bits of old band-aids for a strap.
I think you are being massively oversensitive.
British telecom is the major telecommunicati ons provider in the UK When
I go to pay my bill I get this: https://www2.bt.com/youraccount?coex...cefkdffndfkn.0
When I go to pay my gas bill: http://www.house.co.uk/cgi-bin/house...ergy_acq_nov05
Electricity is a bit more friendly http://www.npower.com/At_home/Custom...ll_online.aspx
No.html anywhere.
Now tell me, exactly what is worrying you about .php ?
--
Geoff Berrow (put thecat out to email)
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/
d wrote: So you come up with a better test, sunshine.
It's your assertion therefore you are burdened with the prove. You asked me to do research, I did.
Oh I can say I times 2 files and it took 100% as long. Meaningful? No. I gave you figures, and suddenly they're not good enough for you.
That's because you gave meaningless figures. And, in case you didn't notice, I did 150 files to give a 150x
demonstration of the difference in required processing, not to
represent the average load of the server.
The average load of the server is what's important. Even someone with a basic grasp of statistics could see that. I never
claimed I was representing your average webserver's daily load.
Then your proof is meaningless. So I see you haven't written code for anything approaching massive
sites, if you claim that. Thanks.
Yeah, where exactly do you see that?
d wrote: I don't code sites for just your average user.
So then, by definition, you are the exception to the rule. No big deal
really. But you shouldn't expect people to agree with you. If you're selling your company, or indeed a product, to people who know,
People who know and people who care are two entirely different worlds. then things like this speak very highly of the attention you pay to
your work.
Yeah it's says your a pinhead, hellbent on spending many resources for
foolish consistencies. It's like making a great watch, then using bits of old band-aids for a
strap.
Hardly. It's more like making a great watch and then adorning it on the
inside where nobody can really see it. If you were really concerned about this, wouldn't the best solution
be to remove 'extensions' from URLs entirely? If you want to relieve
the user of this 'burden', then hiding the mechanics should be the
ultimate goal.
Now you have it :) I moved from the .html-only set-up to my own site
engine, which does indeed do away with extensions altogether.
Where might that be? But once you have code great HTML, great CSS, great PHP, and you
server is quick, smooth and working well, it doesn't make sense to
just stop making your site better.
You've neglected to define what "better" is. All you've said is that the
URLs should end in .html. I've never heard a single person say to me
"Yeah great site! But their URLs don't end in .html so I'm never going
back" and I don't think you have every heard that either! I won't stop until my site is as perfect as possible.
A sure sign of a neurotic person!
--
I have six locks on my door all in a row. When I go out, I lock every
other one. I figure no matter how long somebody stands there picking the
locks, they are always locking three. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: saayan |
last post by:
Hi,
I am using PHP 5.0.1 with Apache 2 on Win XP (SP2).
My index.php file has require_once contents.php and also for
functions.php.
My contents.php file also has a require_once for functions.php.
When this code is tested on one machine, it works fine. However on
another machine with identical configuration (same PHP 5.0.1, XP+SP2,
Apache 2), an error message appears :
|
by: bb nicole |
last post by:
Below is my php code which i need to save the jobseeker resume in database. But does not function and show the message: Column count doesn't match value count at row 1 after i add a field name resume_ID as a primary key in phpMyadmin. i dont know what is the error i done. Thanks.
do_resume.php
<?php
include_once("database.php");
class user {
|
by: comp.lang.php |
last post by:
I am using CLI PHP to run a PHP script, c:\wamp\php\php.exe, but
instead of executing my script, it's actually displaying the raw code
instead.
How can I run my code using CLI PHP? I installed WAMP5 on WinXP.
Thanx
Phil
|
by: sandeepifw |
last post by:
plz help
I have a php variable $content on page menu.php
now i wnt to use its value on page menu_items.js
hear menu_items.js create a menubar.its contan both static and dynamic menu
my lase menu as vander is dynamic now how can i use this variable on .js
my js file look like
|
by: priestyuk |
last post by:
Hi everyone: D,
I recently purchased a very smart and ‘expensive’ template from .
You have to install it on your site etc putting in your mysql details, e-mail address, license key etc. So far everything went to plan. Installed perfect. But now it’s running I am getting a list of these messages on my site (www.illuminati-gaming.co.uk):
Brace yourself:
This is a major pain in the back side as its plastered everywhere. Could...
| | |
by: sickboy |
last post by:
Hey everyone,
I am working on a new site, ForceFedTV.com and I have gotten reports that the site runs great on mac, but once loaded on a pc, after clicking a few links then going back to the home button, they claim they get all black and nothing else.
I am working with an index script that incorporates php to create something like frames.
If someone can access the site and maybe even try and speculate on this, that would be great,
...
|
by: Benjamin Grieshaber |
last post by:
Hi,
I´m on SuSE 9.3 with xmlrpc-c and xmlrpc-c-devel installed (ver. 0.9.10)
I tried to compile php with xmlrpc support and got the following errors:
ext/xmlrpc/.libs/xmlrpc-epi-php.o(.text+0x359): In function
`set_zval_xmlrpc_type':
/php-5.2.5/ext/xmlrpc/xmlrpc-epi-php.c:1313: undefined reference to
`XMLRPC_CreateValueDateTime_ISO8601'
|
by: mekalai82 |
last post by:
i have information.php file that file contain following coding <?php
echo phpinfo(); ?>
while i calling the URL ("http://localhost/information.php").
i am getting the coding <?php echo phpinfo(); ?>
not show the php information...... i am new to the php can you help me?
|
by: Patriot89 |
last post by:
I have a quick question in reference to php file extenstions...
I have code for example like this... This is all located on this site www.ixalliance.com/BHS/Default
(This is my nav.php file)
<div class="navstyle" id="navmenu">
<ul>
<li><a href="index.php">Home</a></li>
<li><a href="administration/admin.php" rel="dropmenu1">Administration</a></li>
|
by: Chrisjc |
last post by:
Good afternoon,
I am seeking some php configuration help. Here is the run down I am running Windows server 2003 and IIS V6.0 I have never had issues before until now. I have Symantec Antivirus 11.0 Manager, it controls all the Symantec clients in the company.
Now it uses a web interface for all of its commands and settings which is called (SEPM) This reporting unit uses php, Symantec by default is loading its php.ini from “C:\Program...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
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 Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
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 protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| | |
