|
Well, I wrote a little test app that includes only the code necessary to build a dialog box with an embedded property sheet, and ran it on three windows 2000 systems. It worked on every one of them. This leads me to the conclusion that it's something else in the app that's crashing when the dialog box in question is being initialized.
"Good thing" - It wasn't my dialog box code that was causing the problem
"Bad thing" - I still don't know what the problem actually is yet.
Grrrr...
|
|
|
|
|
What is the difference between ADO and ADODB?
Thanks.
|
|
|
|
|
What is the difference between ADO and ADODB?
Thanks.
|
|
|
|
|
What is the difference between ADO and ADODB?
Thanks.
|
|
|
|
|
What is the difference between ADO and ADODB?
Thanks.
|
|
|
|
|
Hi,guys
There's a question troubled me for a long while,that is
How can I know a process is RUNNING or NOT RESPONDING in my program,using Visual c++?
anyone can supply useful info is appriciate
|
|
|
|
|
thought i posted an answer to this when you originally posted the question
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
You might check out the docs for SendMessageTimeout . Looks to me like this might be the method Task Manager uses to send an initial WM_CLOSE to a process' main window. All you're really checking for here is if the message pump is pumping - if the app is just dutifully computing the first 23 gazillion digits of e, it will appear hung.
|
|
|
|
|
This is probably really easy .. but here goes
I have a CButton object in my dialog application and I have the x,y,x2,y2 coordinates of the actual dialog application but need to find out what the x,y coordinates of the top/left of the button object. How is this done?
Thanks in advance,
|
|
|
|
|
If you have a variable to the button
CRect rc;
m_myButton.GetWindowRect(&rc);
otherwise
CRect rc;
GetDlgItem(IDC_MYBUTTON)->GetWindowRect(&rc);
I believe this comes in co-ordinates relative to the dialog, in which case ClientToScreen will five you screen co-ords. If I am wrong, ScreenToClient gives you client co-ords.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Ok. I'm a VB/(wannabe Java/C#) programmer so don't flame me. I'm in a C++ class in college and my professor gave the class an odd assignment. I have no clue where to begin. Here is the problem:
Given the program:
#include <iostream.h>
main () {
cout<<” Hello, World\n”;
}
Modify it to produce the output:
Initialize
Hello, World
Clean up
Do not change main () in any way.
Now this is blowing my mind. He said there was a way to override the main function but I do not see how. Any help would be greatly appreciated. Thanks.
MCSD, MCSE
|
|
|
|
|
You don't overload (that's the term, not override) main(), you just write it.
THe way I'd do it is make a class with a constructor that prints "Initialize" and a destructor that prints "Clean up" and declare a global variable of that class. Globals are constructed before main() is called, and destructed after it returns.
--Mike--
http://home.inreach.com/mdunn/
I'm finger-lickin' good!
|
|
|
|
|
I meant overload, I'm always interchanging them by accident. Anyway, my teacher's English is not very good and I posted this during class. I talked with him and a few students and we all misunderstood him. Apparently, he wants us to somehow derive from ostream or streambuf and overload operator<< for cout. Not quite sure how but that is what he said. Thanks for the help.
However, I tried your approach but the destructor is never called.
Here is the output:
Initialize
Hello, World
Press any key to continue
Here are some code snippets:
//MyClass.h
class MyClass
{
public:
MyClass();
~MyClass();
};
//MyClass.cpp
MyClass::MyClass()
{cout << "Initialize\n";}
MyClass::~MyClass()
{cout << "Clean up\n";}
// test.cpp
#include <iostream>
#include "MyClass.h"
using namespace std;
MyClass myClass = MyClass();
int main()
{
cout << "Hello, World\n";
return 0;
}
MCSD, MCSE
|
|
|
|
|
I was in the process of coming up with a similar response when I saw Michaels reply, so I jumped into VC to give it a try, and the following
#include <iostream.h>
class MyClass
{
public:
MyClass() {cout << "Initialize\n";};
~MyClass() {cout << "Clean up\n";};
};
MyClass myClass = MyClass();
int main()
{
cout << "Hello, World\n";
return 0;
}
worked fine for me. I don't believe myClass needs to be defined, but I left it that way ;0)
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I was in the process of coming up with a similar response when I saw Michaels reply, so I jumped into VC to give it a try, and the following
#include <iostream.h>
class MyClass
{
public:
MyClass() {cout << "Initialize\n";};
~MyClass() {cout << "Clean up\n";};
};
MyClass myClass = MyClass();
int main()
{
cout << "Hello, World\n";
return 0;
}
worked fine for me. I don't believe myClass needs to be defined, but I left it that way ;0) I noticed you had a .cpp file for MyClass, but it did not include MyClass.h ??
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
It does have an include, I just didn't paste it it. I copied your example exactly, added the missing include for iostream, and compiled. I came across something quit odd.
When I compile the app using:
#include <iostream>
using namespace std;
The destructor for myClass is never executed.
However, when I use:
#include <iostream.h>
with the namespace line removed, the destructor fires.
Anyone have a clue as to why?
MCSD, MCSE
|
|
|
|
|
Funny enough, I couldn't get a compile at all using namespace std, so I took it out. I have a question. Of what use is
#include
by itself ?
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
#include (according to the strict definition) causes the preprocessor to insert the named file where the #include directive is found as if it were typed there by the coder
my thoughts:
if the name following the directive is blank the preporcessor will either ignore the directive (smart move) or try to include the filename "" (dumb move as this would cause an error file-not-found) ... so actually i guess it ignores the directive
heh
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
|
That's about what I thought it would do, it appears the iostream include ( which I put in myself ) was actually what that line did in the original posters code...
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Nothing.. I had <iostream> after the #include. However, I wasn't using the HTML escape sequence for < and > like I am now so <iostream> is being interpreted as an HTML tag and not being displayed. Actually, codeproject is removing them. It occured in your posts also. Use & lt; for < and & gt; for >. Be sure to remove the space between the & and the other characters.
Also, to use using namespace std, you have to remove the .h from iostream. Don't know why but that is how it works for me.
MCSD, MCSE
|
|
|
|
|
I see, it all becomes clear ;0)
When you #include between <> instead of quotes, you are telling the compiler to load from the standard library as opposed to a header from elsewhere, it doesn't do a search for the file elsewhere ( at least that's from memory, my copy of Stroustrup is at work and I am not )
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
Hey everybody,
I need to redirect the output of a console app to a listbox on a dialog.
I've been trying to do this for a while, to no avail. Its becoming a pain in the ass...
Anyways, what I've done is customize my console app's STARTUPINFO struct to redirect STDOUT to a handle that I specify as well as hide the console window.
The standard ouput is redirected to into a char* buffer that I read from to provide entries into the cells of a listbox on a dialog.
I use CreateProcess to run the console app with the specified STARTUPINFO structure.
In particular, I'm trying to run gzip.exe.
The console app runs fine. Its output is displayed in the console window but it is not in the list box as it should be.
This is the first time I've had to use CreateProcess directly. I've gone through my code and MSDN again and again but I'm still missing something.
Can anyone provide any insight into this situation.
Thanks,
Josh
josh@schroff.com
|
|
|
|
|
Greetings Programs,
I've run into an odd problem and I was looking for some advice.
The following line is from an application I am building:
hFind = FindFirstFile(strcat(cQueueDupe, "\\*.*"), &findData);
Initially I build the application to run as a console app but have decided to expand it into and Windows Service app. As a console application any path I give it will is fine as long as it is valid. Local disks, mounted volumes or UNC paths. Doesn't matter. However, after implimenting the same code as a service (and starting it as a seperate thread from the service thread) the FindFirstFile statement fails for anything that isn't a local disk. At first I thought perhaps I was sloppy in my thread implimentation and removed it but to no avail.
I must admit that I am absolutely at my wits end over this. Hopefully one of you fine persons can show me the error of my ways.
Many thanks,
Rhoam
|
|
|
|
|
FindFirstFile statement fails for anything that isn't a local disk.
That happens because the service is not running under your account, so it doesn't have access to your mapped drives. You'll need to go to the service's properties and set it to log in as you.
--Mike--
http://home.inreach.com/mdunn/
I'm finger-lickin' good!
|
|
|
|
|
OhMyDearGodHowStupidCanIPossiblyBe!
Michael, thank you so much for that. I cannot beleive that such an obvious and common element was completely overlooked in my debugging.
This is by far the dumbest thing I have ever done. Well, except maybe the time I was really drunk and the monkey...
Thanks again,
Rhoam
|
|
|
|