Why is Firefox complaining with this error:
------------------------------------------------------------
missing ) after argument list
setTimeout('bre akOut',5000);
------------------------------------------------------------
Here is the HTML that I'm producing:
<html>
<head>
<script type="text/javascript">
<!--
function breakOut() {
top.location.hr ef = 'https://foo.com';
}
// -->
</script>
<body onLoad="setTime out('breakOut() ',5ØØØ);">
You have been logged out of the control panel due to inactivity for
your security.
</body>
</html>
Dec 14 '05
69  16944 
Matt Kruse wrote: Thomas 'PointedEars' Lahn wrote: They have Javascript/JScript/etc. In these implementations
of ECMAScript, I've not seen one yet that didn't treat
<!--
as a single-line comment. In fact, they document it as so. Where?
I've seen it in the past, but I don't know of a current location. I'm not
going to waste time looking for it.
So you are refusing to prove your own assumption. That makes the assumption
worthless.
One reference to it is in javascript: The Definitive Guide, 3rd edition,
page 30:
"In addition to C++ and C-style comments, client-side Javascript
recognizes the HTML comment opening sequence <!--. Javascript treats this
as a single-line comment, just as it does the // comment."
Ahhh yes, bad old JSTDG. Not its first flaw and I am afraid not its last.
Just test it yourself in any browser:
<script type="text/javascript">
<!-- junk
alert('x');
<!-- more junk
<!-- even more
alert('y');
</script>
Point me to a single browser that fails that test.
Logical fallacy of shifting the burden of proof. Then the closing comment tag
^^^^^^^^^^^^^^^ ^^^^
(Aaargh!)
Semantics games are boring. [...]
This is no game, it is fact that there is no "comment tag".
I have already explained why.
PointedEars
Matt Kruse wrote: Michael Winter wrote: Point me to a single browser that fails that test. And if no reader of this group can, that proves that it will always
work?
Nope, certainly not. I was just pointing out that the "potentiall y
harmful" argument is invalid, because it's not. No known browser will be
^^^^^^^^^^^^^^^ ^ harmed by it, [...]
There is the flaw of your argument.
PointedEars
Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM: Matt Kruse wrote:
Michael Winter wrote:
Point me to a single browser that fails that test.
And if no reader of this group can, that proves that it will always
work?
Nope, certainly not. I was just pointing out that the "potentiall y
harmful" argument is invalid, because it's not. No known browser will be
^^^^^^^^^^^^^^^ ^harmed by it, [...]
There is the flaw of your argument.
Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Randy Webb wrote: Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM: Matt Kruse wrote:Michael Winter wrote:
> Point me to a single browser that fails that test.
And if no reader of this group can, that proves that it will always
work?
Nope, certainly not. I was just pointing out that the "potentiall y
harmful" argument is invalid, because it's not. No known browser will be
^^^^^^^^^^^^^^^ ^ harmed by it, [...]
There is the flaw of your argument.
Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
Again only your usual ad-hominem rubbish. Here are some _facts_ for you to
think about regarding comment delimiters within `script' elements, whether
used as a means to "comment out" the entire script or as single-line
comment prefix:
0. That code should not be parsed by the markup parser, but by the script
engine. There is no documentation that script engines in current
HTML UAs regard markup comment delimiters als script comment delimiters,
and there is proof that at least one script engine, the JavaScript
Reference Implementation, known as SpiderMonkey and used in Mozilla/5.0
based browsers, does not (as using them in external scripts results in a
SyntaxError).
1. It is impossible to clearly define "known browsers", so you cannot
make sure all existing browsers "support" that, let alone all
existing HTML user agents. If you use it, inevitably you make code
non-interoperable, which is in sharp contrast to the purpose of HTML.
As usual, inference from the special case to the general case is
considered harmful.
2. You cannot make sure that future HTML user agents will still "support"
that. If you continue to use it, you make code non-future-proof, IOW
error-prone, which also is in sharp contrast to HTML, considering that
it has always been upwards compatible.
3. There is not a single HTML UA that is still usable today that does
not support the `script' element in terms of recognizing it and
ignoring it if not applicable; if there is one that also supports
HTML 3.2 and greater, it is _badly_ _broken_ (especially when it
considers CDATA content within the `head' element content to display)
and should not be supported at all.
4. Continuing that practice in XHTML either comments out the entire
script element (so that it is not even passed to the script engine)
or results in an invalid document; for XHTML that usually means that
the document cannot be used as XML applications must be well-formed.
So far for Reality, and your narrow perception of it, if that.
PointedEars
--
Learn to think clearly.
Learn to distinguish: What is, and what seems to be. -- Surak
Thomas 'PointedEars' Lahn wrote: 0. [...] there is proof that at least one script engine, the
JavaScript Reference Implementation, known as SpiderMonkey
and used in Mozilla/5.0 based browsers, does not (as using
them in external scripts results in a SyntaxError).
I have to take that back and to state the opposite. That SyntaxError
was apparently caused by other code, so it appears that JavaScript-C
1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
apparently as an undocumented extension to ECMAScript.
x <!-- y
z
yields "foo.js:1: ReferenceError: x is not defined".
/*x*/ <!-- y
z
yields "foo.js:2: ReferenceError: z is not defined". If `<!--' was
considered a SyntaxError by that implementation and not a prefix for
a single-line comment, that error message should have been regarding
it (because of the missing operand left-hand side), not `z'.
However, it is important to emphasize that this does not invalidate
the rest of this point or any of the other points I made. Other
conforming implementations , including future releases of the same
implementation, are not required to extend ECMAScript in the same way.
PointedEars
___________
[1] The stand-alone engine compiled here
with gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)
from <URL:http://ftp.mozilla.org/pub/mozilla.org/js/js-1.5.tar.gz>
and fed with a plain text ISO-8859-1 .js file with both Windows
line delimiters (0x0D 0x0A; first test of both variants) and
UNIX line delimiters (0x0A; second test of both variants).
Thomas 'PointedEars' Lahn wrote: I have to take that back and to state the opposite. That SyntaxError
was apparently caused by other code, so it appears that JavaScript-C
1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
apparently as an undocumented extension to ECMAScript.
x <!-- y
z
yields "foo.js:1: ReferenceError: x is not defined".
/*x*/ <!-- y
What in the name are you talking about? What "foo.js" ?!? Naturally you
cannot insert HTML/XML/SGML/Hell-ML markup into stay-alone script file.
That will fail in any browser, no need to involve any monkeys.
This discussion (before it got a bit crazy atmosphere) was about script
source text directly inserted into HTML page (***HTML*** - not sick
sh** XHTML, not XML, not SGML, not SVG, not VML, not Perl, not PHP, not
anything else).
But even for XHTML:
"Defining Abstract Modules"
This section is normative.
<http://www.w3.org/TR/xhtml-modularization/abstraction.htm l>
<quote>
Script data can be the content of the "script" element and the value of
intrinsic event attributes. User agents must not evaluate script data
as HTML markup but instead must pass it on as data to a script engine.
</quote>
That removes the question out of the HTML/XHTML parsing engine
authority. Sorry if my language is not academical enough but I say as I
can: anything between <script>...</script> tags has to be taken *as it
is* and forwarded right to the script interpreter. But you already
admitted it.
Therefore any tag parser which would try to *anyhow* interprete <!--//
.... //--> within the <script> tags is badly brocken or abusively
non-standard. From this point forward it doesn't matter what will it
see: an SGML block or Holy Marie with a bunch of angels.
"Hiding script data from user agents"
<http://www.w3.org/TR/html40/interact/scripts.html#h-18.3.2>
That is a very clear text written on surprisingly "human" language -
which is not so often for W3C.
Still hiding the script content into comment is obsolete and kinda
overkill precaution in the year 2005/2006 - but no one is arguing with
that.
VK wrote: Thomas 'PointedEars' Lahn wrote: I have to take that back and to state the opposite. That SyntaxError
was apparently caused by other code, so it appears that JavaScript-C
1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
apparently as an undocumented extension to ECMAScript.
x <!-- y
z
yields "foo.js:1: ReferenceError: x is not defined".
/*x*/ <!-- y
What in the name are you talking about? What "foo.js" ?!?
The foo.js file I created to contain the above lines of script code.
(It really helps to think before you post once in a while.)
Naturally you cannot insert HTML/XML/SGML/Hell-ML markup into stay-alone
script file.
The point is that SpiderMonkey does not consider that to be markup.
That will fail in any browser, no need to involve any monkeys.
It will not fail in _all_ browsers. I have sufficiently proven that it
will probably not fail in current Gecko-based browsers because AIUI they
will need to implement SpiderMonkey for XUL.
This discussion (before it got a bit crazy atmosphere) was about script
source text directly inserted into HTML page (***HTML*** - not sick
sh** XHTML, not XML, not SGML, not SVG, not VML, not Perl, not PHP, not
anything else).
So? If we assume that the markup parser is standards compliant in parsing
the CDATA content of the HTML `script' element, it depends on the script
engine to support this comment syntax. The same script engine would parse
external script files, and SpiderMonkey does support it, as I have proven.
But even for XHTML:
"Defining Abstract Modules"
This section is normative.
<http://www.w3.org/TR/xhtml-modularization/abstraction.htm l>
<quote>
Script data can be the content of the "script" element and the value of
intrinsic event attributes. User agents must not evaluate script data
as HTML markup but instead must pass it on as data to a script engine.
</quote>
That removes the question out of the HTML/XHTML parsing engine
authority.
No, quite the contrary. Besides, you are citing from XHTML Modularization
used for XHTML 1.1 and newer which is a different thing.
"Hiding script data from user agents"
<http://www.w3.org/TR/html40/interact/scripts.html#h-18.3.2>
That is a very clear text written on surprisingly "human" language -
which is not so often for W3C.
Examples are not normative, and that section was written before RFC2854
was issued. Unfortunately, a clarification has not yet been added to the
errata:
<URL:http://www.w3.org/MarkUp/html4-updates/errata>
Still hiding the script content into comment is obsolete and kinda
overkill precaution in the year 2005/2006 - but no one is arguing
with that.
Exactly. (Once in a while, even you have your bright moments.)
PointedEars
Thomas 'PointedEars' Lahn said the following on 12/18/2005 5:56 PM: Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 12/17/2005 1:42 PM:
Matt Kruse wrote:
Michael Winter wrote:
>>Point me to a single browser that fails that test.
>
>And if no reader of this group can, that proves that it will always
>work?
Nope, certainly not. I was just pointing out that the "potentiall y
harmful" argument is invalid, because it's not. No known browser will be
^^^^^^^^^^^^^^^ ^
harmed by it, [...]
There is the flaw of your argument.
Your flaw, both you and your arguments, is that you don't know the
difference between Reality and Theory.
Again only your usual ad-hominem rubbish.
Coming from you, that is amusing.
Here are some _facts_ for you to think about regarding comment delimiters
within `script' elements, whether used as a means to "comment out" the entire
script or as single-line comment prefix:
Give some references to your "facts". And please do not quote ECMA to
me, I don't buy it as a valid reference for web scripting. It is nothing
more than a theory about how things should be.
0. That code should not be parsed by the markup parser, but by the script
engine. There is no documentation that script engines in current
HTML UAs regard markup comment delimiters als script comment delimiters,
Fix your spell checker or your keyboard. It is "as", not "als". For you
to be so pedantic about others typos you seem to make them yourself.
People who live in glass houses shouldn't throw stones at the neighbors.
and there is proof that at least one script engine, the JavaScript
The language is Javascript, not JavaScript.
Reference Implementation, known as SpiderMonkey and used in Mozilla/5.0
based browsers, does not (as using them in external scripts results in a
SyntaxError).
Irrelevant. Give one browser, just one that produces a syntax error with
this code:
<script type="text/javascript">
<!--
//-->
</script>
And then you might have an argument. Its more Theory vs Reality. Theory
is that it should be an error, Reality is that no browser throws an
error with it. Never has and never will for no other reason than
backwards compatibility.
1. It is impossible to clearly define "known browsers", so you cannot
make sure all existing browsers "support" that, let alone all
existing HTML user agents. If you use it, inevitably you make code
non-interoperable, which is in sharp contrast to the purpose of HTML.
As usual, inference from the special case to the general case is
considered harmful.
I didn't ask for all "known browsers". I ask for *one* browser that
throws an error with the above code. Until one is shown to throw an
error, it is irrelevant what the "specs" say. What is relevant is what
the browser does with the code.
2. You cannot make sure that future HTML user agents will still "support"
that. If you continue to use it, you make code non-future-proof, IOW
error-prone, which also is in sharp contrast to HTML, considering that
it has always been upwards compatible.
That's your opinion, not a fact. It is a non-refutable opinion just as
me saying they will support backwards compatibility is irrefutable.
Neither can be proven, neither can be disproved. I can say this though:
Let's assume, for this argument, that IE7 balks on not having those
comments in a script block. Do you think people will stop supporting IE7
because it is not "standards compliant" or do you think people will
start adding them back? If you guess non-support, you couldn't be more
wrong.
Standards do not come from ECMA and W3C as they should. The standards,
browser behavior, and what is or is not supported is decided in Redmond
Washington in the USA.
Note the use of the term "should".
3. There is not a single HTML UA that is still usable today that does
not support the `script' element in terms of recognizing it and
ignoring it if not applicable; if there is one that also supports
HTML 3.2 and greater, it is _badly_ _broken_ (especially when it
considers CDATA content within the `head' element content to display)
and should not be supported at all.
No argument there. With the exception of "should not be supported at
all". If you want to thumb your nose at potential customers because of
the browser, then that is your choice. I can give you a real world
example of that happening though.
2 years ago I was forced to use NN4 as a browser. No amount of begging
the higher-ups would let me upgrade the browsers. The Sales Department
wanted to use a web site to order from. The site used JS to submit forms
instead of a normal submit button. It wouldn't work for us. The cost to
the company that couldn't get our business? 100,000 US dollars.
Now, if you are told that you can gain 100,000 dollars US by supporting
an older browser you can bet anything you want that the pencil pushers
will have you bending over backwards to support that browser. That's
Reality. The Theory is : You should upgrade your browser.
4. Continuing that practice in XHTML either comments out the entire
script element (so that it is not even passed to the script engine)
or results in an invalid document; for XHTML that usually means that
the document cannot be used as XML applications must be well-formed.
Considering that the #1 browser on the web doesn't support XHMTL to use
XHMTL as an argument is ridiculous.
--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Thomas 'PointedEars' Lahn wrote: I have to take that back and to state the opposite. That SyntaxError
was apparently caused by other code, so it appears that JavaScript-C
1.5 2004-09-24 (SpiderMonkey) [1] considers `<!--' the same as `//',
apparently as an undocumented extension to ECMAScript.
This is standard behavior for every JScript/Javascript/ECMAScript
implementation I have ever seen.
Just because it is not documented in ECMAScript specs doesn't mean it is not
documented. In fact, for it to be documented in ECMAScript would be rather
odd, since its only need would be in a browser context. It's not the DOM,
either. So I'm not sure where it would be documented, other than in language
references for specific implementations .
Keep in mind, a browser implementing <script type="text/javascript"> doesn't
need to support ECMAScript either. If a browser implemented a pure
ECMAScript engine which followed specs and chose to make things like:
<script type="text/ecmascript">
<!-- x
</script>
a syntax error, I would agree with you that it's expected. But browsers
support Javascript/JSCript, which have functionality beyond ECMAScript. And
the <script> tag says text/javascript, not text/ecmascript.
The behavior of <!-- is most certainly documented. I just don't have links
archived, and unfortunately it's difficult to search for on the web. Current
documentation may omit the details of this special functionality because it
is usually no longer needed or recommended, but previously it was most
certainly there. Even archive.org is giving me errors tonight, so I'm not
going to waste time looking for the docs. It's kind of a moot point anyway.
--
Matt Kruse http://www.JavascriptToolbox.com http://www.AjaxToolbox.com
Randy Webb <Hi************ @aol.com> writes: and there is proof that at least one script engine, the JavaScript
The language is Javascript, not JavaScript.
Actually, the official name for the language used by the Netscape
browsers and inheriteed by the Mozilla based browsers, including the
Spidermonkey engine, is "JavaScript ". This is also the name that is
trademarked by Sun Microsystems, Inc.
I personally use "Javascript " to refer to the group of languages
derived from JavaScript, including JScript and the ECMAScript
implementations in other browsers, but it's not an official name.
Irrelevant. Give one browser, just one that produces a syntax error
with this code:
<script type="text/javascript">
<!--
//-->
</script>
Can't find one. It would be stupid for a browser creator to not accept
this, since so many existing pages use it. That's not an argument for
using it, or advocating its use. It's not even an argument against
arguing for its abolishment.
Can you find one browser later than Netscape 2, i.e., one that
understands the script element, that doesn't work without the "syntax
of an HTML comment"?
And then you might have an argument. Its more Theory vs
Reality. Theory is that it should be an error, Reality is that no
browser throws an error with it. Never has and never will for no other
reason than backwards compatibility.
Correct. And there is no reason not to remove it.
It will be a problem when somebody unknowingly (which is the reason
people use it in the first place) adds XML comments to an XHTML
file, and removes their entire script before it ever reaches the
script interpreter.
I didn't ask for all "known browsers". I ask for *one* browser that
throws an error with the above code. Until one is shown to throw an
error, it is irrelevant what the "specs" say. What is relevant is what
the browser does with the code.
Are you arguing that standards are irrelevant and that we should just
go by what the browsers do? That validation is irrelevant, as long as
it works in all the current browsers?
Standards do not come from ECMA and W3C as they should. The standards,
browser behavior, and what is or is not supported is decided in
Redmond Washington in the USA.
While IE is a de-facto standard, it is not the only standard. As I see
it, more and more people are writing pages to standards and adding
support for IE afterwards. That is probably why Microsoft admits that
standard support is one of the primary requests for IE 7.
Admittedly, if all browsers supported all standards equally well,
there wouldn't be any compelling reason to choose one over the other,
except the user interface. I can see Microsoft not wanting to compete
that way.
Considering that the #1 browser on the web doesn't support XHMTL to
use XHMTL as an argument is ridiculous.
It's not an argument for not using a deprecated practice in HTML
documents, where I agree that it will probably be supported forever,
but for trying to break the habit of the people using it in order
to avoid the problem when they eventually try to write an XHTML page
(especially when it seems to work in IE because it doesn't parse
it as XML).
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.' This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Alex Vinokur |
last post by:
Various forms of argument passing
=================================
C/C++ Performance Tests
=======================
Using C/C++ Program Perfometer
http://sourceforge.net/projects/cpp-perfometer
http://alexvn.freeservers.com/s1/perfometer.html
|
by: Conrad Weyns |
last post by:
vc7.1 has no problem with the following snippet:
template <typename T> class TTest
{
std::list<T*>::iterator m_It;
};
but metrowerks codewarrior 9.2 kicks my butt and online Comeau confirms:
1. MW:
|
by: soup_or_power |
last post by:
I'm passing the return from window.open as a function argument and
getting the error "missing ] after element list" when tested with
FireFox. Here is the relevant code. Many thanks for your help.
function blurCkbox(num, disp, but_id, sugg)
{
if (num == 1) {
eval("self.opener.document.forms." + but_id + ".value=\'" +
sugg + "\'");
|
by: Ville Vainio |
last post by:
I tried to clear a list today (which I do rather rarely, considering
that just doing l = works most of the time) and was shocked, SHOCKED
to notice that there is no clear() method. Dicts have it, sets have it,
why do lists have to be second class citizens?
|
by: ehsansad |
last post by:
I have the following code.
function updateTermsList() {
var termDivBox = document.getElementById("termarea");
var terms = searchXMLHttp.responseXML.getElementsByTagName("term");
for(var i=0;i<terms.length;i++){
var name = terms.childNodes.firstChild.nodeValue;
var value = new String(terms.childNodes.firstChild.nodeValue);
var a = document.createElement('div');
| | |
by: Vv_vV |
last post by:
Hi all,
I try to call onchange a function and get "missing ) after argument
list" error
Probably systaxis issue
Thanks in advance for any help!
Code:
var html = "";
var myurl = "http://www.example.com/url.php?dummy=";
|
by: deedub65 |
last post by:
I am getting a "Missing ) after argument list" on two different sets of commands in the same script - they are part of Dreamweaver MX's files, so i am not sure how they got altered - thanks for the help!
function canAcceptCommand()
{
// Make sure the focus is in the BODY of the document.
var retVal = false;
if (dw.getFocus() == 'document' && dw.getDocumentDOM().getFocus() == 'body') {
retVal = true;
}
if...
|
by: Pasquale |
last post by:
I am attempting to populate a few select drop down menus from the
selection of the first drop down. I am using ajax to submit data via a
PHP GET and from the response populate the other drop down menus.
I figured out how to get it to do so for more than one drop down, but I
am getting the following error below. This was working fine until I
tried to populate more than one other drop down menu. Any idea why the
SELECT object isn't being...
|
by: A. Anderson |
last post by:
Howdy everyone,
I'm experiencing a problem with a program that I'm developing. Take a
look at this stack report from GDB -
#0 0xb7d782a3 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d4c2f7 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d6441b in vsprintf () from /lib/tls/i686/cmov/libc.so.6
#3 0x08049ba0 in character_data::printf (this=0x800, argument=0x0)
at character.c:198
|
by: hariomt |
last post by:
Hi,
i have to create table's rows dynamically.
I am using bellow code snipet...
function copySelectedAttr()
{
var attrValue= document.getElementById('fromEntityAttrBox').options.text;
var attrtype=document.getElementById('fromEntityAttrBox').value;
|
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
| | |
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
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: 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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
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: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
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: 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...
| |
