|
bigjoe11a wrote: whats codeproject
It is a magical world full of programming knowledge.
Did you ever read the content of your browser's address box? Do it now!
Ever noticed the Search box on top of this page? Use it!
|
|
|
|
|
Except Lounge forum that we have,its other world ont the codeproject.
|
|
|
|
|
I have been there and done that and still can't find what I'm looking for. thats why I posted this message.
|
|
|
|
|
|
bigjoe11a wrote: The only code I can find is dated 1998 and older.
All three of those protocols are MUCH older than that
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yes, I know I downloaded some just to find out that it's not what I wanted.
Most of those are just samples for FTP uploads and things like that. Theres nothing there about FTP Servers or Telnet Servers or even SMTP servers
One more thing your forums section doesn't seem to inform me of posts. So sorry I didn't know until I thought to check any way.
|
|
|
|
|
|
No I'm sorry it's not. Most of the links that I have were not related to a Telnet, FTP and a SMTP servers. Just client applications
and the ones I did find are more then 8 years old.
|
|
|
|
|
what can be done so that when user key in their ID for example, the program will run without having to push any command button?
|
|
|
|
|
belle wrote: what can be done so that when user key in their ID for example, the program will run...
At the time of user input, isn't the program already running?
belle wrote: ...without having to push any command button?
What button are you talking about. After the user's ID has been verified, do whatever comes next.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
DavidCrow wrote: belle wrote:
what can be done so that when user key in their ID for example, the program will run...
At the time of user input, isn't the program already running?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
can you speak detail?
what input and command button?
|
|
|
|
|
Your question is very vague...
If you mean: I want my program to run as soon as the user has logged on... then put your program in the startup group.
If you mean: I have an edit box in my program - as soon as the user has finished typing their name do something, and don't wait for them to click a button, then look at EN_CHANGE notification from the edit box.
That's all I can guess.
Iain.
|
|
|
|
|
I have this in one of my header files:
#define BufferSize 16384
(I know macros are usually defined with all caps)
The problem is that if this header file is included before windows.h, I get compiler errors. The preprocessor goes through and substitutes 16384 for BufferSize. Since there is a "BufferSize" token in one of the windows headers, winbase.h, the compiler chokes on it when it attempts to compile my project.
So I'm looking for alternative ways of defining a global constant. This constant needs to be used to define array sizes. Unfortunately, that means that this:
extern const int BufferSize;
Doesn't work.
I'm thinking about creating class with only static members, so I can do this:
class SynthToolkit
{
public:
static const int BufferSize = 1684;
};
And I can use it elsewhere like so:
buffer[SynthToolkit::BufferSize];
But before I do this, I wanted to ask here to see if anyone has a better solution. Thanks.
|
|
|
|
|
Leslie Sanford wrote: Unfortunately, that means that this:
extern const int BufferSize;
Doesn't work.
Why not?
You can have this in a header file so any module that needs it
knows it exists somewhere...
extern const int BufferSize;
and you need the instance in exactly ONE (CPP) module...
const int BufferSize = 16384;
Your alternative method is nice because it's wrapped in a class,
which will help prevent future name collisions. You could use the global
variable in a different namespace as well.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Why not?
Unless I'm missing something, you can't do this:
extern int BufferSize;
#include "SynthToolkit.h"
class SomeClass
{
private:
buffer[BufferSize];
};
The reason, I'm guessing, is that the compiler can't resolve the size of "BufferSize" at compile time, so it doesn't know the size of the array.
|
|
|
|
|
But he didn't it. He declared BufferSize as const .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
CPallini wrote: But he didn't it. He declared BufferSize as const.
Leaving out const was a typo on my part. I stand by my original point. An integer constant with external linkage can't be used to declare the size of an array at compile time.
I would love to be corrected on this if I'm wrong.
|
|
|
|
|
You're correct You'll need a constant, so again, the second
method is better.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Leslie Sanford wrote: I stand by my original point. An integer constant with external linkage can't be used to declare the size of an array at compile time.
You can use it in the source file (there must be one) that defines (assigns) the const variable.
Anyway, on the overall, you're right.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
CPallini wrote: You can use it in the source file (there must be one) that defines (assigns) the const variable.
Anyway, on the overall, you're right.
Ah, I see what you mean. With internal linkage, the integer constant can be used to determine the size of an array at compile time. My declaration that it "doesn't work" was too broad. It does work with internal linkage, but not external.
Thanks for the clarification. I've learned something new.
|
|
|
|
|
Using a different name is not possible?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Good question!
How was this conflict avoided up 'til now?
Why is it coming up now?
|
|
|
|
|
Member 754960 wrote: How was this conflict avoided up 'til now?
Why is it coming up now?
I've been tying in the GUI code, which is Windows based, to the non-GUI code, which is agnostic about what platform it's on.
|
|
|
|
|
OK. As that would be a different discussion, I'll only say that I would try to maintain that separation.
As for the macro, you should be able to define the constant directly in the header file,
const int BufferSize = 16384;
The compiler should accept this when defining your arrays,
void f()
{
char buf[Buffersize];
}
and the linker should resolve multiple references in files just as it would with any other constant.
The question then becomes if this constant needs to be exposed outside of the non UI code and hence in a project wide include file. Is the intent that the standard application bufer size is a constant or just those of the non UI code? Why should any other module know this?
|
|
|
|