|
Anonymous wrote:
The want you to use .NET.
Fine, I'll use .NET. Oh yeah, .NET is missing even more features for stand-alone application development. (Actually, I really would use .NET IF I had some clear indication Microsoft was going to enhance it for stand-alone application development and not let it wither like MFC/ATL/WTL....)
This is my gripe: I'll use whatever Microsoft is going to push for the future. Problem is that they are being half-assed about every possible solution!
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
Joe Woodbury wrote:
that MFC does not support the XP look and feel.
Isn't that what the manifest is for? Tell XP what your App shall look like.
Do not ask me about details - my company is just leaving NT4, and we are developing under W2K.
Who is 'General Failure'? And why is he reading my harddisk?!?
|
|
|
|
|
The manifest gets you partly there.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
Have you looked at CNewMenu here on CP. This is easy to integrate into existing apps. Also Prof-UIS gives you all the latest look and feel, but doc's aren't the best. I use CNewMenu in ED (see sig) and Prof-UIS in a new app I'm working on. See: www.prof-uis.com[^]
Neville Franks, Author of ED for Windows. Free Trial at www.getsoft.com
|
|
|
|
|
I'll look at CNewMenu today after going over some code I found on CodeGuru. I'll also look at Prof-UIS, which sounds like it has the same problem as everyone else: bad docs.
Joe Woodbury
When all else fails, there's always delusion.
- Conan O'Brien
|
|
|
|
|
I'm thinking of how a linked list verifies whether a given node pointer points to a valid node in the list.
For example, suppose we have a linked list which chains up 10000 NODE, the user calls one member functions which takes a NODE* as parameter: InsertBefore(const NODE* pBefore, LPVOID lpData), now how does the linked list verify if pBefore points to a valid NODE which is contained in the list? I think basically there would be 2 possibilities:
Solution 1, Use ::IsValidReadPtr and ::IsValidWritePtr to check if the memory is available to current process and the consecutive memory block space are large enough to be read/written against a NODE object.
Solution 2, Travel through the whole list and exam pBefore with address of each NODE, stops whenever a match is found.
Personally I think solution 2 is definitely a no go because that would make the linked list ultimately slow if it contains a larget amount of nodes. Solution 1 is faster but not safe, because that way we cannot really make sure if pBefore really points to a NODE or not, it could be any object whose size is same or greater than a NODE and if we use some iterating method like while (pNode->pNext != NULL) {...;} we'll get our system hang...
So I really want to know how a linked list verify a NODE*, is there any better solution, thanks.
|
|
|
|
|
AFAIK, many linked lists use the "honor system"... that is, when you insert a node, it takes your word for it that it's a valid node. 
The STL linked list uses iterators for this purpose, which makes it less likely to err. You can still mess up if you pass in a list an iterator from a different list, though.
If your nose runs and your feet smell, then you're built upside down.
|
|
|
|
|
I don't think there is any way you could 100% guarantee that a node passed to one of the member functions was valid. However, you could add an extra member to the NODE that was a pointer back to the linked list. This would reduce the chances of a node being passed in from another list, but even that is still not a guarantee that it is valid.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
how could i place two more toolbars in just one row?
Thank you, anyway!
Hello World!
|
|
|
|
|
|
I have a ReBar on this rebar has one toolbar and one DialogBar. The DialogBar contains a ComboBox.
On this comboBox I am not able to do copy/paste buy use keyboard. But when I right mouseclick I get copy/paste menu.
How can I enable the copy/paste through Keyboard ?
Sandeep Naik
|
|
|
|
|
Hi all. New here to coding kind of. Check out the following code.
#include "iostream.h"<br />
#include "cstdio.h"<br />
#include "cstring.h"<br />
<br />
int main()<br />
{<br />
char str[80];<br />
cout << "Enter a sentence: ";<br />
gets (str)<br />
cout << "\nYou entered: " << str<br />
<br />
return 0;<br />
}
What it does is nothing, but prompts you to enter the string BEFORE it couts "Enter a sentence: ". Why would this be, cout is clearly supposed to be executed before the statement gets (str);.
How the heck does it get that out of what I coded. Wrong version of VC or something ? using MS VC 6.0. How can this be. I am banging my head against the wall.  lol
Thank you much people.
|
|
|
|
|
I don't know, how about a carriage return after "Enter a sentence\n" ?
|
|
|
|
|
If I remember, add a "endl" to the end.
i.e.
count << "Enter a sentence: " << endl;
An endl not only adds a CR/LF, it also flushes the output buffer.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
You're mixing iostreams (cout) and stdio (gets), so the streams are not synchronized.
This should work:
#include "iostream.h"
#include "stdio.h"
#include "string.h"
int main()
{
char str[80];
cout << "Enter a sentence: ";
cout.flush();
gets (str);
cout << "\nYou entered: " << str;
return 0;
}
As should this:
#include <iostream>
#include <string>
int main()
{
std::string str;
std::cout << "Enter a sentence: ";
std::getline(std::cin, str);
std::cout << "\nYou entered: " << str;
return 0;
}
(But, for some reason I don't understand, the latter requires you to hit enter twice.)
--------
There are 10 types of people in this world. Those who know binary and those who don't.
|
|
|
|
|
So, if that is true, then why would Herb Schildt produce this code in his book(C++ from the Ground Up, 3rd edition):
#include "iostream.h"<br />
#include "cstdio.h"<br />
<br />
<br />
int main()<br />
{<br />
char str[80];<br />
<br />
cout << "Enter a string: ";<br />
gets(str); <br />
cout << "Here is your string: ";<br />
cout << str;<br />
<br />
return 0;<br />
}
It might make sense that the two streams are not synchronized which is the only thing I could think of, however Mr. Schildt has produced otherwise. Possibly a different compilor configuration?
Mr. Schildt shows this in his book:
Enter a string: This is a test<br />
Here is your string: This is a test
|
|
|
|
|
#include "iostream.h"
This is the old way of including the C++ standard headers, which indicates that the book may be a bit outdated. The new headers don't have an extension, e.g.:
#include <iostream><br />
#include <cstdio>
It is up to the iostreams implementation to decide how to handle buffering, and some older implementations may have synchronization between iostreams and stdio turned on by default.
- Mike
|
|
|
|
|
Okay, however it is due to my mistake that the includes are listed as so. I had actually changed the <iostream> to "iostream.h" because the web forum didn't display that till I figured out that feature.
Which leads me to my main point, which is how am I supposed to learn this book of the stuff doesn't compile. I paid alot of money for this book, and I don't think it's old either.
|
|
|
|
|
I haven't read any of the C++ books by Herb Schildt, but I've heard both good and bad things about them. The edition you mentioned was published in March 2003, which is indeed fairly recent, so I would expect it to follow more modern conventions.
The code snippet you posted earlier should work fine (it compiles fine in VC6 for me, with the using namespace std; line and the includes changed to their modern versions) since all the input is coming from one type of stream and all the output is going to another type of stream. The problem arises when you read in data from two different types of streams or write data to two different types of streams.
Stylistically, I would argue that mixing cstdio and iostream is generally a bad idea, even in a case like this. Also, gets() is inherently unsafe, since the program would break if a line longer than 80 characters was entered. Hopefully, this was noted in the book. If not... eep. 
shawnsch wrote:
how am I supposed to learn this book of the stuff doesn't compile.
What was the compiler error? I'm curious, since, as I mentioned, I just tried it in VC6 and it compiled and ran. Here is the version I tried:
#include <iostream><br />
#include <cstdio><br />
<br />
using namespace std;<br />
<br />
int main()<br />
{<br />
char str[80];<br />
<br />
cout << "Enter a string: ";<br />
gets(str); <br />
cout << "Here is your string: ";<br />
cout << str;<br />
<br />
return 0;<br />
}
- Mike
|
|
|
|
|
Hello,
I have a question that should be easy but I'm having a major brain fart..
How would one copy a char/buffer into a structure? I know this isn't correct but it may help you understand what im trying to do...
memcpy((char FAR*)&sMyStruct, pBuff, sizeof(pBuff));
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Assuming pBuff is a pointer to an array of bytes, this won't work because sizeof(pBuff) will always return 4 (the size of the pointer). You need to pass in the actual number of bytes to copy instead.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
That was it, thanks..
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
I'm trying to place a value in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run so that my app starts up when windows starts up, as a background app. I've implemented DLLRegisterServer so that it is invoked when the setup.exe runs (I've set the .exe to self-register under InstallShield). In DLLSelfRegister, I need the path to the .exe so that the value in the registry is set properly and the .exe runs from that path. I use GetModuleFileName to get the path of the app, but when regsvr32 myApp.exe is run, the app is not instantiated yet.
I used MFC to create a dialog based app
Here's a code snipet:
CSysTrayDemoApp theApp; //MFC generated
...
//Implement this funciton so that regsvr32 can invoke it to register exe.
STDAPI DllRegisterServer()
{
char path[MAX_PATH];
DWORD pathLen = sizeof(fileName);
__asm int 3;
GetModuleFileName(theApp.m_hInstance, path, pathLen);
...
theApp.m_hInstance is not instantiated and thus I can't get the path name.
Does anyone have experience in registering an app/is there a better way of doing this?
Thanks,
Raymond
|
|
|
|
|
Try passing in NULL as the HINSTANCE for GetModuleFileName() - that means it retrieves the name of the current module. The most likely reason for theApp.m_hInstance not being initialised is that DllRegisterServer normally does not need to call DllMain(), so your normal application initialisation has not occurred.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
As you are registering EXE -- this is outproc server.
Why would you need regsvr32 for that (it's used for inproc servers)?
Instead, you should start your outproc server with /REGSERVER and process it properly in yours InitInstance (or whatever)...
"...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..."
Me
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
