I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
40  2592  fi********@indiatimes.com wrote: I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
I can write it under windows, linux, or even mac...
But
***it will not be free of course! ***
What wonders me is that people think they will get here people
ready to work for free for them.
If you pay for it then you can have it. If not... just write it yourself! fi********@indiatimes.com wrote: I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
--
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
return 0;}
Further Info. : http://www.dcs.warwick.ac.uk/~esubbn/
__________________________________________________ _____
Yu SONG wrote: fi********@indiatimes.com wrote: I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
--
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
Better written as:
int main (void) {
printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
You need to add a \n to ensure the string is actually printed ;)
return 0;}
Robert Gamble
"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com... Yu SONG wrote: fi********@indiatimes.com wrote: > I need a program in C (something like a TSR) which will automatically
> press the function key F6, say about every 5 seconds. Can anyone
> provide me with an exe of such a program?
> Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
Better written as:
int main (void) { printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
You need to add a \n to ensure the string is actually printed ;)
No he doesn't...
return from main is equivalent to calling exit() with value returned.
exit() function must flush all unwritten buffered data.
therefore: return 0;}
Will be enough to ensure the string is actually printed. :P
Mark
Mark wrote: "Robert Gamble" <rg*******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Yu SONG wrote:
fi********@indiatimes.com wrote:
I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
Better written as:
int main (void) {printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
You need to add a \n to ensure the string is actually printed ;)
No he doesn't...
return from main is equivalent to calling exit() with value returned.
exit() function must flush all unwritten buffered data.
therefore:return 0;}
Will be enough to ensure the string is actually printed. :P
But he does need to end the the last line of output with a '\n' to have
portable behavior. The most common kind of implementation-specific
behavior is whether the prompt overwrites the last line when not so
terminated. When the prompt does overwrite that line, that line might
disappear before even noticed, so appears never to have been printed.
Mark wrote: "Robert Gamble" <rg*******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com... Yu SONG wrote: fi********@indiatimes.com wrote:
> I need a program in C (something like a TSR) which will automatically
> press the function key F6, say about every 5 seconds. Can anyone
> provide me with an exe of such a program?
> Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
Better written as:
int main (void) { printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
You need to add a \n to ensure the string is actually printed ;)
No he doesn't...
return from main is equivalent to calling exit() with value returned.
exit() function must flush all unwritten buffered data.
therefore:
return 0;}
Will be enough to ensure the string is actually printed. :P
This is true, however there is a good chance the string will be
overwritten or mangled by the command prompt when the program returns
to a shell. Let me rephrase: You should add a \n to increase the
chances of the printed string being seen by the user.
Robert Gamble
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:x4****************@newsread2.news.atl.earthli nk.net... Mark wrote: "Robert Gamble" <rg*******@gmail.com> wrote in message
news:11*********************@g49g2000cwa.googlegro ups.com...
Yu SONG wrote:
fi********@indiatimes.com wrote:
>I need a program in C (something like a TSR) which will automatically
>press the function key F6, say about every 5 seconds. Can anyone
>provide me with an exe of such a program?
>Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
Better written as:
int main (void) {
printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
You need to add a \n to ensure the string is actually printed ;) No he doesn't...
return from main is equivalent to calling exit() with value returned.
exit() function must flush all unwritten buffered data.
therefore:return 0;}
Will be enough to ensure the string is actually printed. :P
But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
The behavior of the application is portable with or without the newline.
The most common kind of implementation-specific behavior is whether the
prompt overwrites the last line when not so terminated.
I don't see 'the most common kind of implementation-specific behavior' in my
standard...
nor any reference to this 'prompt' that you speak of. Can you provide a
reference point?
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
Stop making crap up and pretending that there is merit to your words. :P
Regards,
Mark
Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:x4****************@newsread2.news.atl.earthli nk.net...
But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
The behavior of the application is portable with or without the newline.
7.19.2/2: "[...] Whether the last line requires a
terminating new-line character is implementation-defined."
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
If it's going to a file, say, you may find it instructive
to read a little further along in 7.19.2/2: "Data read in from
a text stream will necessarily compare equal to the data that
were earlier written out to that stream only if: [...] the last
character is a new-line character."
Stop making crap up and pretending that there is merit to your words. :P
.... but this parting shi\bot makes me wonder whether you are in
a frame of mind receptive to instruction. "Don't confuse me with
the facts: my mind is made up!"
-- Er*********@sun.com
Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:x4****************@newsread2.news.atl.earthli nk.net...
But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
The behavior of the application is portable with or without the newline.
Jane , you Ignorant Slut. Please learn something before your mouth-off.
Among the things that the implementation must specify is, according to
the standard,
-- Whether the last line of a text stream requires a
terminating new-line character (7.19.2).
And 7.19.2 tells us
[#2] A text stream is an ordered sequence of characters
composed into lines, each line consisting of zero or more
characters plus a terminating new-line character. Whether
the last line requires a terminating new-line character is
implementation-defined. Characters may have to be added,
altered, or deleted on input and output to conform to
differing conventions for representing text in the host
environment. Thus, there need not be a one-to-one
correspondence between the characters in a stream and those
in the external representation. Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist |
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character. Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.
The most common kind of implementation-specific behavior is whether the
prompt overwrites the last line when not so terminated.
I don't see 'the most common kind of implementation-specific behavior' in my
standard...
nor any reference to this 'prompt' that you speak of. Can you provide a
reference point?
It is obvious to anyone that can actually read that I was referring to
actual conditions in the real world, not about the standard making
claims about them. But that wouldn't matter to you, since you obviously
have not read the standard at all. Note the wide range of
implementation-specific behavior that the text of the standard (above)
does mention.
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
I don't presume any such thing. If you are incapable of understanding
the word 'might', then there is no hope for you.
Stop making crap up and pretending that there is merit to your words. :P
Good advice. It's time for you totake it, you slimy toad.
In article <11*********************@f14g2000cwb.googlegroups. com>,
Robert Gamble <rg*******@gmail.com> wrote:
.... This is true, however there is a good chance the string will be
overwritten or mangled by the command prompt when the program returns
to a shell. Let me rephrase: You should add a \n to increase the
chances of the printed string being seen by the user.
Just keep in mind that if "the standard" said that 2+2 = 17, then the
regulars in this group would assert that as fact. They will then tend to
become violent if you even so much as assume that anything else could
possibly be true.
And, to be fair, within the context of this newsgroup, they would be
absolutely right. That is, within the context of this newsgroup, 2+2 *IS*
(and I cannot stress that too strongly) seventeen.
On Wed, 08 Jun 2005 18:13:25 GMT, in comp.lang.c , "Mark"
<so***@localbar.com> wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
Before arguing with CLC regulars, check the Standard.
The behavior of the application is portable with or without the newline.
Nope, its implementation defined.
I don't see 'the most common kind of implementation-specific behavior' in my
standard...
Dur. Thats because its implementation-specific, and by definition not
covered by the standard.
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
Why not? Its a possible destination, and in fact was the one probably
intended by the original example.
Stop making crap up and pretending that there is merit to your words. :P
Er, check in the mirror...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
I love this group. Let's never try to become so politically correct
that we loose the whit and charm.
It's brilliant. Also lots of good material.
THanbks
gm
In article <d8**********@yin.interaccess.com>,
Kenny McCormack <ga*****@interaccess.com> wrote: Just keep in mind that if "the standard" said that 2+2 = 17, then the
regulars in this group would assert that as fact.
Unary representation grouped in octal notation??
[I know, I know, unary isn't one of the representations allowed in
the standard. ;-) ]
--
Oh, to be a Blobel!
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:jU****************@newsread3.news.atl.earthli nk.net... Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:x4****************@newsread2.news.atl.earthli nk.net...But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
The behavior of the application is portable with or without the newline.
Jane , you Ignorant Slut.
Very nice.
Please learn something before your mouth-off.
Teach me oh might guru.
Among the things that the implementation must specify is, according to the
standard,
-- Whether the last line of a text stream requires a
terminating new-line character (7.19.2).
And how do you interpret that?
A line, by definition (which you already quoted later in this message)
consists of 0 or more chars plus a terminating newline.
My interpretation of that statement is: depending on your implementation
the terminating new-line character on the last line may be optional.
Keeping in mind that the terminating new-line is required on all others
I think that's the only way that statement truly can be interpreted.
Now, when writing to stdout using printf() each line written IS the 'last'
line.
consider:
printf("some prompt:");
fflush(stdout);
Is this portable? I think so, but maybe I'm mistaken.
Will it output a 'line'? No, because it's missing the terminating new-line.
It will output a partial line... that being: "zero or more characters plus a
terminating new-line character" sans the new-line character.
Isn't that legal? I think so, but maybe I'm mistaken.
Isn't that one of the purposes of fflush()?
And 7.19.2 tells us
[#2] A text stream is an ordered sequence of characters
composed into lines, each line consisting of zero or more
characters plus a terminating new-line character. Whether
the last line requires a terminating new-line character is
implementation-defined. Characters may have to be added,
altered, or deleted on input and output to conform to
differing conventions for representing text in the host
environment. Thus, there need not be a one-to-one
correspondence between the characters in a stream and those
in the external representation. Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist |
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character. Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.
Thank you, you've provided the definitions for text streams, and lines.
Once again for review: a line is required to contain a terminating new-line
unless it is the last line, in which case it is implementation defined as to
whether or not it is required. Agreed?
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It doesn't.
The most common kind of implementation-specific behavior is whether the
prompt overwrites the last line when not so terminated.
I don't see 'the most common kind of implementation-specific behavior' in
my standard...
nor any reference to this 'prompt' that you speak of. Can you provide a
reference point?
It is obvious to anyone that can actually read that I was referring to
actual conditions in the real world, not about the standard making claims
about them.
I thought the purpose of this group was to talk about the standard and
the claims made by it, no? Did I accidentally stumble into
comp.real.world.claims ???
But while we're on the subject,
Unixes don't typically reset the position of the prompt...
MS windows/dos boxes typically spit out an extra newline when your
application finishes before displaying the prompt.
On what 'real world' condition do you notice this behavior?
But that wouldn't matter to you, since you obviously have not read the
standard at all.
Bits and pieces... a lot of bits and pieces. Never did read the entire
thing
straight through though... I still peruse sections from time to time
though.
Nice piece of documentation to keep handy ;)
Note the wide range of implementation-specific behavior that the text of
the standard (above) does mention.
Yes, but code containing 'implementation-specific' behavior is still
considered 'portable'... no?
If it wasn't then the only true valid definition for main() would have to
be:
int main(void); - no?
5.1.2.2.1
-- If the value of argc is greater than zero, the array
members argv[0] through argv[argc-1] inclusive shall
contain pointers to strings, which are given
implementation-defined values by the host environment
prior to program startup.
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
I don't presume any such thing. If you are incapable of understanding the
word 'might', then there is no hope for you.
I understand 'might', but that was not the issue... the word in question was
'prompt' .
If you don't presume a terminal, then please explain what you meant by
'prompt' :P
Stop making crap up and pretending that there is merit to your words. :P
Good advice. It's time for you totake it, you slimy toad.
Take my own advice?
Let's take another look at the original statements in question.
RG> You need to add a \n to ensure the string is actually printed ME>
return from main is equivalent to calling exit() with value returned.
ME> exit() function must flush all unwritten buffered data.
Do you have an argument with my statement?
Granted, last line may not be (on some implementations) a 'line' but
regardless, it will still be printed.
MA>But he does need to end the the last line of output with a '\n' to have
MA>portable behavior
ME>The behavior of the application is portable with or without the newline.
Again, do you have an argument with my statement? It's quite possible that
the data in question may not be visible on some systems, but that is caused
by something happening 'after' the program in question has completed... not
caused by the behavior of the application as it runs. The application
itself
cannot control what happens when it completes, consider an OS which may
clear the entire terminal upon executing your utility or do away with the
window
completely... does that make your application 'non-portable'... I would
think not.
Mark
Mark wrote: Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It doesn't.
Jane, you Ignorant Slut.
I never made such a claim.
To recap: Mark wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:x4****************@newsread2.news.atl.eart hlink.net...
But he does need to end the the last line of output with a '\n' to
haveportable behavior.
Another erroneous statement.
The behavior of the application is portable with or without the newline.
Please learn some honesty along with the ability to read.
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.earthli nk.net... Mark wrote:
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It
doesn't.
Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
I never made such a claim.
Nor did I claim that you did.
I was pointing out that the data must be written after the fflush().
Please learn some honesty along with the ability to read.
You snipped the entire message without responding to the
contents and accuse me of not being honest or able to read...
Please take your own advice.
Now let's try this again, if you can manage to converse intelligently,
tell me where I'm mistaken. (or you can take the easy way out and
insult me without contributing anything remotely intelligent... again!)
<reposting snipped portions of previous message for sake of discussion>
Among the things that the implementation must specify is, according to the
standard,
-- Whether the last line of a text stream requires a
terminating new-line character (7.19.2).
And how do you interpret that?
A line, by definition (which you already quoted later in this message)
consists of 0 or more chars plus a terminating newline.
My interpretation of that statement is: depending on your implementation
the terminating new-line character on the last line may be optional.
Keeping in mind that the terminating new-line is required on all others
I think that's the only way that statement truly can be interpreted.
Now, when writing to stdout using printf() each line written IS the 'last'
line.
consider:
printf("some prompt:");
fflush(stdout);
Is this portable? I think so, but maybe I'm mistaken.
Will it output a 'line'? No, because it's missing the terminating new-line.
It will output a partial line... that being: "zero or more characters plus a
terminating new-line character" sans the new-line character.
Isn't that legal? I think so, but maybe I'm mistaken.
Isn't that one of the purposes of fflush()?
And 7.19.2 tells us
[#2] A text stream is an ordered sequence of characters
composed into lines, each line consisting of zero or more
characters plus a terminating new-line character. Whether
the last line requires a terminating new-line character is
implementation-defined. Characters may have to be added,
altered, or deleted on input and output to conform to
differing conventions for representing text in the host
environment. Thus, there need not be a one-to-one
correspondence between the characters in a stream and those
in the external representation. Data read in from a text
stream will necessarily compare equal to the data that were
earlier written out to that stream only if: the data consist |
only of printing characters and the control characters
horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last
character is a new-line character. Whether space characters
that are written out immediately before a new-line character
appear when read in is implementation-defined.
Thank you, you've provided the definitions for text streams, and lines.
Once again for review: a line is required to contain a terminating new-line
unless it is the last line, in which case it is implementation defined as to
whether or not it is required. Agreed?
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It doesn't.
The most common kind of implementation-specific behavior is whether the
prompt overwrites the last line when not so terminated.
I don't see 'the most common kind of implementation-specific behavior' in
my standard...
nor any reference to this 'prompt' that you speak of. Can you provide a
reference point?
It is obvious to anyone that can actually read that I was referring to
actual conditions in the real world, not about the standard making claims
about them.
I thought the purpose of this group was to talk about the standard and
the claims made by it, no? Did I accidentally stumble into
comp.real.world.claims ???
But while we're on the subject,
Unixes don't typically reset the position of the prompt...
MS windows/dos boxes typically spit out an extra newline when your
application finishes before displaying the prompt.
On what 'real world' condition do you notice this behavior?
But that wouldn't matter to you, since you obviously have not read the
standard at all.
Bits and pieces... a lot of bits and pieces. Never did read the entire
thing
straight through though... I still peruse sections from time to time
though.
Nice piece of documentation to keep handy ;)
Note the wide range of implementation-specific behavior that the text of
the standard (above) does mention.
Yes, but code containing 'implementation-specific' behavior is still
considered 'portable'... no?
If it wasn't then the only true valid definition for main() would have to
be:
int main(void); - no?
5.1.2.2.1
-- If the value of argc is greater than zero, the array
members argv[0] through argv[argc-1] inclusive shall
contain pointers to strings, which are given
implementation-defined values by the host environment
prior to program startup.
When the prompt does overwrite that line, that line might disappear
before even noticed, so appears never to have been printed.
Disappear? From what? You assume output is going to a terminal... why?
I don't presume any such thing. If you are incapable of understanding the
word 'might', then there is no hope for you.
I understand 'might', but that was not the issue... the word in question was
'prompt' .
If you don't presume a terminal, then please explain what you meant by
'prompt' :P
Stop making crap up and pretending that there is merit to your words. :P
Good advice. It's time for you totake it, you slimy toad.
Take my own advice?
Let's take another look at the original statements in question.
RG> You need to add a \n to ensure the string is actually printed ME>
return from main is equivalent to calling exit() with value returned.
ME> exit() function must flush all unwritten buffered data.
Do you have an argument with my statement?
Granted, last line may not be (on some implementations) a 'line' but
regardless, it will still be printed.
MA>But he does need to end the the last line of output with a '\n' to have
MA>portable behavior
ME>The behavior of the application is portable with or without the newline.
Again, do you have an argument with my statement? It's quite possible that
the data in question may not be visible on some systems, but that is caused
by something happening 'after' the program in question has completed... not
caused by the behavior of the application as it runs. The application
itself
cannot control what happens when it completes, consider an OS which may
clear the entire terminal upon executing your utility or do away with the
window
completely... does that make your application 'non-portable'... I would
think not.
Mark
Mark wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.earthli nk.net... Mark wrote:
Now,
where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It
doesn't.
Jane, you Ignorant Slut.
Who is Jane?
Jane Curtain
--
pete
Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.earthli nk.net...
Mark wrote:
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It
doesn't.
Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
Poor kid can't even Google.
-- Er*********@sun.com
"Eric Sosman" <er*********@sun.com> wrote in message
news:d8**********@news1brm.Central.Sun.COM...
Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.earthli nk.net...
Mark wrote:
Now, where in the standard does it state that it implementations may
choose to disregard 'partial' lines that have been fflush()ed? It
doesn't.
Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
Poor kid can't even Google.
Actually, that was 'my' poor attempt at being funny :P
But feel free to kick in with a post that actually contributes
something to the discussion Eric. You are one of the
brighter posters on CLC and I'd hate for you to limit your
response to: 'poor kid can't even google.'
Mark
Mark wrote: "Martin Ambuhl" <ma*****@earthlink.net> wrote in message
.... snip ...
Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
All he is proving is that he has watched SNL from the 70s, and
picked up the rudest and most ignorant phrases therefrom.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Mark wrote: "Eric Sosman" <er*********@sun.com> wrote in message
news:d8**********@news1brm.Central.Sun.COM...
Mark wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.eart hlink.net...
Mark wrote:
>Now, where in the standard does it state that it implementations may
>choose to disregard 'partial' lines that have been fflush()ed? It
>doesn't.
Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
Poor kid can't even Google.
Actually, that was 'my' poor attempt at being funny :P
But feel free to kick in with a post that actually contributes
something to the discussion Eric. You are one of the
brighter posters on CLC and I'd hate for you to limit your
response to: 'poor kid can't even google.'
Well, I gave a citation from the Standard. You're choosing
to impose some sort of contorted Topsy-Turvy-Land mis-reading,
and I can't rescue you from your folly. What's left besides
innocent merriment?
--
Eric Sosman es*****@acm-dot-org.invalid
Mark McIntyre wrote: "Mark" <so***@localbar.com> wrote:"Martin Ambuhl" <ma*****@earthlink.net> wrote in message But he does need to end the the last line of output with a '\n' to have
portable behavior.
Another erroneous statement.
Before arguing with CLC regulars, check the Standard.
The behavior of the application is portable with or without the newline.
Nope, its implementation defined.
No. Whether the last line _requires_ a newline is implementation
defined.
The behaviour of a program that fails to supply such a newline on an
implementation which requires it is technically undefined.
Members of the committee have commented that the only difference is
whether or not the last (newline free) line is actually output or not.
[Output to old line printers is a classic example. You won't see a line
until it encounters a newline.]
--
Peter
"Eric Sosman" <es*****@acm-dot-org.invalid> wrote in message
news:j_********************@comcast.com... Mark wrote: "Eric Sosman" <er*********@sun.com> wrote in message
news:d8**********@news1brm.Central.Sun.COM...
Mark wrote:
"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
news:nK****************@newsread3.news.atl.ear thlink.net...
>Mark wrote:
>
>
>
>>Now, where in the standard does it state that it implementations may
>>choose to disregard 'partial' lines that have been fflush()ed? It
>>doesn't.
>
>Jane, you Ignorant Slut.
Who is Jane? Your mother? Your wife?
Or is that your poor attempt to be funny?
Poor kid can't even Google.
Actually, that was 'my' poor attempt at being funny :P
But feel free to kick in with a post that actually contributes
something to the discussion Eric. You are one of the
brighter posters on CLC and I'd hate for you to limit your
response to: 'poor kid can't even google.'
Well, I gave a citation from the Standard. You're choosing
to impose some sort of contorted Topsy-Turvy-Land mis-reading,
and I can't rescue you from your folly. What's left besides
innocent merriment?
"Contorted Topsy-Turvy-Land mis-reading"???
Once again, my interpretation of the citation in question is:
a line is required to contain a terminating new-line unless it happens
to be the last line, in which case it is implementation defined as to
whether or not a new-line is required.
Please, enlighten me... what am I mis-reading?
Mark wrote:
"Eric Sosman" <es*****@acm-dot-org.invalid> wrote in message
news:j_********************@comcast.com... Mark wrote: "Eric Sosman" <er*********@sun.com> wrote in message
news:d8**********@news1brm.Central.Sun.COM...
Mark wrote:
>"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
>news:nK****************@newsread3.news.atl.ear thlink.net...
>
>
>>Mark wrote:
>>
>>
>>
>>> Now, where in the standard does it state
>>> that it implementations may
>>> choose to disregard 'partial' lines
>>> that have been fflush()ed? It doesn't.
"Contorted Topsy-Turvy-Land mis-reading"???
Once again, my interpretation of the citation in question is:
a line is required to contain a terminating new-line unless it happens
to be the last line, in which case it is implementation defined as to
whether or not a new-line is required.
Please, enlighten me... what am I mis-reading?
If a newline character is required,
then a partial line isn't a line.
Line semantics wouldn't apply to partial lines.
--
pete
"pete" <pf*****@mindspring.com> wrote in message
news:42***********@mindspring.com... Mark wrote: "Eric Sosman" <es*****@acm-dot-org.invalid> wrote in message
news:j_********************@comcast.com... > Mark wrote:
>> "Eric Sosman" <er*********@sun.com> wrote in message
>> news:d8**********@news1brm.Central.Sun.COM...
>>>Mark wrote:
>>>>"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
>>>>news:nK****************@newsread3.news.atl.ear thlink.net...
>>>>>Mark wrote:
>>>>>> Now, where in the standard does it state
>>>>>> that it implementations may
>>>>>> choose to disregard 'partial' lines
>>>>>> that have been fflush()ed? It doesn't.
"Contorted Topsy-Turvy-Land mis-reading"???
Once again, my interpretation of the citation in question is:
a line is required to contain a terminating new-line unless it happens
to be the last line, in which case it is implementation defined as to
whether or not a new-line is required.
Please, enlighten me... what am I mis-reading?
If a newline character is required,
then a partial line isn't a line.
Line semantics wouldn't apply to partial lines.
I've stated as much earlier in the thread... but that is irrelevant.
As you know, fflush() doesn't deal with lines, it deals with unwritten
'data'.
Line semantics aren't the issue. The purpose of fflush() is to deliver the
unwritten data to the host environment, no?
Had the data been terminated with a new-line when written there would
be no need to call fflush(), agreed?
The question amounts to: is fflush() enough to 'portably' ensure that
any unwritten data is delivered to the host environment.
Based on my interpretations of the standard, I think it should be
enough, but apparently others disagree. I'd like to understand why?
Therefore, I ask again, what am I misreading?
Where am I misinterpreting the standard?
I realize this thread may not be as interesting as some of the other
easily answered 'homework' threads everyone seems to jump at,
but I think it warrants proper discussion and it relates directly to
the interpretation of the standard... no?
Mark
In article <ri****************@monger.newsread.com>
Mark <so***@localbar.com> wrote: I've stated as much earlier in the thread... but that is irrelevant.
As you know, fflush() doesn't deal with lines, it deals with unwritten
'data'.
Indeed. But sometimes "text files" (including stdout) require "lines".
Line semantics aren't the issue. The purpose of fflush() is to deliver the
unwritten data to the host environment, no?
Yes, but some host environments are mean, nasty, and rotten.
IBM mainframes in particular tend to be like this.
If you write a "partial line" and fflush() it, nothing comes out!
(They sometimes put a special hack into the stdin-reading code, so
that if you do:
fputs("some prompt: ", stdout);
fflush(stdout);
result = fgets(line, sizeof line, stdin);
the fgets() outputs an extra newline, so that the prompt appears.
But sometimes even that does not happen.)
The question amounts to: is fflush() enough to 'portably' ensure that
any unwritten data is delivered to the host environment.
It gets "delivered" all right, but the mean nasty host does not pass
it on to the user.
Obnoxious, no? But it happens. It is safer to end your last output
line with a newline. This also prevents the output line from being
overwritten by mean, nasty, rotten Unix-clone shells. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
"Chris Torek" <no****@torek.net> wrote in message
news:d8*********@news4.newsguy.com...
Finally, a real guru!
Thanks for responding Chris.
My questions below are not meant to be argumentative or contradictive,
but only to answer a few questions I have. In article <ri****************@monger.newsread.com>
Mark <so***@localbar.com> wrote:I've stated as much earlier in the thread... but that is irrelevant.
As you know, fflush() doesn't deal with lines, it deals with unwritten
'data'. Indeed. But sometimes "text files" (including stdout) require "lines".Line semantics aren't the issue. The purpose of fflush() is to deliver
the
unwritten data to the host environment, no?
Yes, but some host environments are mean, nasty, and rotten.
IBM mainframes in particular tend to be like this.
If you write a "partial line" and fflush() it, nothing comes out!
Doesn't that render the implementation 'non-conforming'?
(They sometimes put a special hack into the stdin-reading code, so
that if you do:
fputs("some prompt: ", stdout);
fflush(stdout);
result = fgets(line, sizeof line, stdin);
the fgets() outputs an extra newline, so that the prompt appears.
But sometimes even that does not happen.)
The question amounts to: is fflush() enough to 'portably' ensure that
any unwritten data is delivered to the host environment.
It gets "delivered" all right, but the mean nasty host does not pass
it on to the user.
Obnoxious, no? But it happens. It is safer to end your last output
line with a newline. This also prevents the output line from being
overwritten by mean, nasty, rotten Unix-clone shells. :-)
Agreed. (Safer) But the real question is portability...
I've mentioned upwards in the thread that it's possible that output
may not be visible for a number of other reasons (such as a terminal
window being closed immediately following program termination, in
which case a new-line won't help) but does the exclusion of a final
new-line written to a text stream make the program 'non-portable'?
Let's forget about terminals for a second... consider the following
trivial utility which attempts to store the date/time of last execution.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int
main(void)
{
FILE *fp = fopen("last.run", "w");
if(fp) {
time_t tt = time(NULL);
struct tm *tms = localtime(&tt);
if(tms != NULL)
fprintf(fp, "%d/%d/%d %d:%d:%d", tms->tm_mon, tms->tm_mday,
tms->tm_year +1900, tms->tm_hour, tms->tm_min,
tms->tm_sec);
fclose(fp);
}
return 0;
}
Does the lack of a new-line prevent this code from being portable?
Is it or is it not a strictly conforming program?
I look forward to any response and plan to let the thread die after that.
Thanks again,
Mark
On 9 Jun 2005 18:41:47 -0700, in comp.lang.c , "Peter Nilsson"
<ai***@acay.com.au> wrote: Mark McIntyre wrote: "Mark" <so***@localbar.com> wrote: >"Martin Ambuhl" <ma*****@earthlink.net> wrote in message
>> But he does need to end the the last line of output with a '\n' to have
>> portable behavior.
>
>Another erroneous statement.
Before arguing with CLC regulars, check the Standard.
>The behavior of the application is portable with or without the newline.
Nope, its implementation defined.
No. Whether the last line _requires_ a newline is implementation
defined.
We're saying the same thing. If the reqirement to have a newline is
implementation defined, then the behaviour in its absence is
implementation defined and unportable.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Fri, 10 Jun 2005 22:53:49 GMT, in comp.lang.c , "Mark"
<so***@localbar.com> wrote: "Chris Torek" <no****@torek.net> wrote in message
If you write a "partial line" and fflush() it, nothing comes out!
Doesn't that render the implementation 'non-conforming'?
Flushing the buffers is not obligated to cause something to appear
onscreen or whatever. After all, when you flush the loo, nothing comes
out of it (hopefully).It is safer to end your last output line with a newline. This also prevents the output line from being
overwritten by mean, nasty, rotten Unix-clone shells. :-)
Agreed. (Safer) But the real question is portability...
Define portable. The definition round here tends to be "works the same
on all platforms", and since we know that newline-less lines don't
always get printed, we can safely say the code isn't portable.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
>"Chris Torek" <no****@torek.net> wrote in message news:d8*********@news4.newsguy.com... ... some host environments are mean, nasty, and rotten.
IBM mainframes in particular tend to be like this.
If you write a "partial line" and fflush() it, nothing comes out!
In article <1S****************@monger.newsread.com>
Mark <so***@localbar.com> wrote:Doesn't that render the implementation 'non-conforming'?
No, because the standard only requires that the bytes be "delivered
to the host environment", which in this particular case means the
runtime libraries the C compiler uses to interface to the OS (MVS,
OS/360, etc.).
Agreed. (Safer) But the real question is portability...
I've mentioned upwards in the thread that it's possible that output
may not be visible for a number of other reasons (such as a terminal
window being closed immediately following program termination, in
which case a new-line won't help) but does the exclusion of a final
new-line written to a text stream make the program 'non-portable'?
It causes the output to be other than desired, at least.
Let's forget about terminals for a second... consider the following
trivial utility [code snipped, but it writes to the file "last.run",
without including a final newline]
Does the lack of a new-line prevent this code from being portable?
Is it or is it not a strictly conforming program?
"Strictly conforming" is not, in a practical sense, a very useful
property of programs. Here is what the Standard (well, C99 draft)
says:
[#1] A strictly conforming program shall use only those
features of the language and library specified in this
International Standard.2 It shall not produce output
dependent on any unspecified, undefined, or implementation-
defined behavior, and shall not exceed any minimum
implementation limit.
It is quite difficult to avoid exceeding *some* "minimum
implementation limit" and all "implementation-defined behavior".
But you asked :-) , so:
What happens on those annoying mainframe-type machines is that the
file may wind up empty, or may have a newline you did not really
want added to it, depending on the chosen output format (usually
selected via JCL or some other ugliness). (The reason is that the
system has too many file formats. One set of file formats, the
"varying length record", consists of a sequence of "records" of
"varying length" -- hence the name. One of the encodings for this
is "byte count of first output line, followed by the line's bytes,
followed by byte count of second output line, followed by the line's
bytes", and so on. A special count means "skip to end of disk
block", after which one resumes the logical-record sequence; logical
records are not normally broken across disk blocks.)
In order for the C library stdio to handle this file format, it
has to count bytes up to the newline:
/* write one character to a file */
void __sputc(FILE *fp, int c) {
... various tests, after which we decide that we have one
of these annoying logical-record files ...
if (c == '\n') {
reclen = fp->__reclen; /* __ names are in our implementor space */
/*
* Write 2-byte record length in host order, to the file
* specified by the File Control Block. Then, if there
* are any bytes, write them. (First skip to new block
* if needed, of course.)
*/
if (fp->__fcb.partblk + reclen + 2 > fp->__fcb.__blksize)
__lib_fcb_padblk(&fp->__fcb);
__lib_fcb_write(&fp->__fcb, &reclen, 2);
if (reclen > 0)
__lib_fcb_write(&fp->__fcb, fp->__buf, reclen);
/*
* Reset record length to zero and return success, because
* we "wrote the newline".
*/
fp->__reclen = 0;
return '\n';
}
/*
* Not a newline: accumulate the byte. Return failure if the
* accumulated record would exceed a single file block.
*/
if (fp->__reclen + 2 > fp->__fcb.__blksize)
return EOF;
fp->__buf[fp->__reclen++] = c;
return c;
}
(This code assumes there is a whole separate wrapper layer,
__lib_fcb_*, that deals with the underlying disk blocks and
accumulating data until one has a full block. In practice, that
code would probably be folded in with the stdio layer. Of course,
in VMS, this code all lies in the RMS system in the "supervisor"
or "executive" [I forget which], so it is not even in the C library
at all! The file control blocks are manipulated via the QIO
system calls, as I recall.)
Whether fclose() and/or the stdio shutdown code (at exit) checks
for fp->__reclen > 0, and appends a newline, is "implementation-defined".
So code that depends on this (by not adding a final newline before
fclose()ing or exit()ing or returning from main) is not "strictly
conforming", using the Standard's definition of "strictly conforming".
The output is one line (including final newline) on Implementation
A, and no lines on Implementation B. (And both differ from Unix-like
systems, where you get a non-\n-terminated line in the file,
creating headaches for someone who wants to count lines. :-) )
The comp.lang.c and/or comp.std.c groups have occasionally
proposed that the Standard should have a term like "strongly
conforming" that would be more useful than "strictly conforming".
A program that fails to print a final newline would probably
be "strongly conforming", even though there would be machines
where nothing gets written.
The folks who edit the standards have never taken this up.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
> Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
HI to all why to use format specifier %s and %c whatever it may be printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
printf("Yu Song's E-mail:"User At Warwick);
This Will Work fine after all User,At,Warwick are the macros and
releted to preprocessor tasks not a variable.
return 0;}
Thanks Junaid
"junaid" <ju*********@yahoo.com> writes: Song
/* E-mail.c */
#define User "Yu.Song"
#define At '@'
#define Warwick "warwick.ac.uk"
int main() {
HI to all why to use format specifier %s and %c whatever it may be printf("Yu Song's E-mail: %s%c%s", User, At, Warwick);
printf("Yu Song's E-mail:"User At Warwick);
This Will Work fine after all User,At,Warwick are the macros and
releted to preprocessor tasks not a variable.
return 0;}
For one thing, only adjacent string literals are concatanated, not
character constants, so the suggested code would be a syntax error.
This is easily avoided by defining At as "@" rather than '@', but that
leaves another potential problem: if one of the defined strings
happens to contain a '%' character, it will be interpreted as a format
specifier if it's part of the format string. Using "%s" avoids this.
There don't happen to be any '%' characters present, but it's still
one less thing to worry about. (I remember when e-mail addresses
often did contain '%' characters.)
If you want to make the code more efficient, you could just print a
single string literal -- but that would violate the whole purpose of
the program, which is to obfuscate the poster's e-mail address, but
not too badly.
Finally, if I had written it, I probably would have added a
"#include <stdio.h>" at the top and a newline at the end of the
output, even though it's not really meant to be a useful program.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Yu SONG <ti**@mi6.gov.uk> scribbled the following: fi********@indiatimes.com wrote: I need a program in C (something like a TSR) which will automatically
press the function key F6, say about every 5 seconds. Can anyone
provide me with an exe of such a program?
Thanks in advance.
Post this to a "specific platform" newsgroup (e.g. Linux, Windows)
28 replies about someone's signature and only one actually answering the
original question. What a newsgroup!
(Signature in question intentionally snipped because it's covered
already)
--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield 28 replies about someone's signature and only one actually answering the
original question. What a newsgroup!
That means we have an eye, which captures even minute things about the
C language, whether it's an intentionally posted question or
someone's signature.
If someone's signatures gives 28 people to talk on technical topics
what's wrong with it? And the plus point is the newcomer like me gets
knowledge from it.
Le 13/06/2005 23:40, dans 11**********************@o13g2000cwo.googlegroups. com, «*junaid*»
<ju*********@yahoo.com> a écrit*:
28 replies about someone's signature and only one actually answering the
original question. What a newsgroup!
That means we have an eye, which captures even minute things about the
C language, whether it's an intentionally posted question or
someone's signature.
If someone's signatures gives 28 people to talk on technical topics
what's wrong with it? And the plus point is the newcomer like me gets
knowledge from it.
Still, nobody has given a clue on the original question... Sad. The parallel
and very interesting discussion about '\n' is not an excuse :-)
> Still, nobody has given a clue on the original question... Sad. The parallel and very interesting discussion about '\n' is not an excuse :-)
I am happy with the first reply i.e. from jacob navia
Because I have objection on the lineprovide me with an exe of such a program?
of the main question.
You not even interested how the program will be implemented and the
logic about it but directly asking for the final result,really a bad
use of the group.
On Mon, 13 Jun 2005 23:51:21 +0200, Jean-Claude Arbaut
<je****************@laposte.net> wrote: Le 13/06/2005 23:40, dans
11**********************@o13g2000cwo.googlegroups .com, «Â*junaidÂ*»
<ju*********@yahoo.com> a écritÂ*:
28 replies about someone's signature and only one actually answering the
original question. What a newsgroup!
That means we have an eye, which captures even minute things about the
C language, whether it's an intentionally posted question or
someone's signature.
If someone's signatures gives 28 people to talk on technical topics
what's wrong with it? And the plus point is the newcomer like me gets
knowledge from it.
Still, nobody has given a clue on the original question... Sad.
It was more like a (underspecified) request for free code :-)
> It was more like a (underspecified) request for free code :-)
Not free code but free exe.
I also appritiate the attempt for the free code.(Being a penguin lover)
I also applogise for the mistake that I have made (not all the
remaining 28 posts are technical some of them are simply personal)and
we also wasting our time (I think)on a nontechnical things.
I am sorry if I have hurted you,but What I mean from my earlier post is
we dont have to miss the chance to learn something new ,I dont care if
it comes from someones signature ,but if the disscussion is going to be
personal it must be stoped.
so I stop here
Thanks
On 13 Jun 2005 15:27:48 -0700, "junaid" <ju*********@yahoo.com> wrote: I also applogise for the mistake that I have made (not all the
remaining 28 posts are technical some of them are simply personal)and
we also wasting our time (I think)on a nontechnical things.
I'd say, roughly, a good 25% of the follow-up posts here are intended
to be personal (looking at the insults contained within them).
I am sorry if I have hurted you
Who? Me? I didn't even note an attempt to hurt my feelings :-)
but What I mean from my earlier post is
we dont have to miss the chance to learn something new
Okay, here's something you might not know. Did you know that fruit
juice (like orange juice or lemon juice) erodes our teeth more than
cola? It's more acidic and keeps its eroding action longer.
Amazing.
It's recommended to rinse your mouth with water after drinking fruit
juice to neutralize the acid. It also helps to use a straw. Human
teeth aren't worth beans. Some of the few liquids that don't erode our
teeth are water, milk and tea.
I dont care if
it comes from someones signature ,but if the disscussion is going to be
personal it must be stoped.
If only it was that easy ;-)
this is fun, but can't we discuss something more important, like string
buffers?!?!
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: asdasd |
last post by:
Hello there,
I'm hoping someone might be able to help me out. Its been awhile since I've
programmed in visual basic (and roughly at that)... I want to create a
program that will allow me to...
|
by: Simon John |
last post by:
I'm writing a PyQt network client for XMMS, using the InetCtrl plugin,
that on connection receives a track length.
To save on bandwidth, I don't want to be continually querying the
server for...
|
by: Charles Law |
last post by:
Here's one that should probably have the sub-heading "I'm sure I asked this
once before, but ...".
Two users are both looking at the same data, from a database. One user
changes the data and...
|
by: pixtudio |
last post by:
I have a problem making a typing tutor program in c.. im using djgpp and running on a windows xp.
my problem is that, how can i be able to let the letters/number fall at the same time.
example:...
|
by: freeman.matt |
last post by:
So I'm writing an interface for my GPS unit and I've come up with a few
questions about how VB works. This is my first experience with a
'visual' programming language, and it's a little differient...
|
by: iCon |
last post by:
Hi, i need to build a program that does this:
-Press Delete every 20 seconds
-Press Insert every 30 seconds
-Do that until the program gets canceled by the user.
Can somebody help me with the...
|
by: Joris De Groote |
last post by:
Hi,
I have wrote a program that checks for files and moves these files to the
correct folders when they come in. Everything works fine. However I always
have to start that program manually. I...
|
by: bshul |
last post by:
Hi,
I am hoping someone knows how to finish this javascript. The script copies selected text to the windows clipboard from, for instance, a webpage. This text is a phone number. It then executes the...
|
by: amitpatel66 |
last post by:
There is always a requirement that in Oracle Applications, the Concurrent Program need to be execute programatically based on certain conditions/validations:
Concurrent programs can be executed...
|
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: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
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...
|
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,...
|
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: 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...
| |
