|
you can also write a standard C-interfaced DLL. most every programming environment out there can handle one.
if you want to write an ActiveX component, you'll need to get a book on it. it's a big subject.
-c
"Should you not have a ramekin of sea salt beside the stove, you don’t deserve oatmeal."
Dean Allen
|
|
|
|
|
All games (I think) have that function that they can find the game server on the network. Do you know how to do that?
Rickard Andersson@Suza Computing
ICQ#: 50302279 (Add me!)
E-mail: nikado@pc.nu
I'm from the winter country SWEDEN!
|
|
|
|
|
Most servers send UDP packets to a master server and get as a response an UDP packet with a list of all the servers currently running.
You may download the sourcecode of "qstat" in order to watch what packets you need to send
modified 12-Sep-18 21:01pm.
|
|
|
|
|
I'm trying to compile some code that uses file streams in VC++ but I'm getting a ton of errors like:
'ios' : ambigious symbol
I've #included iomanip.h and iostream.h and have tried the "using namespace std;" but perhaps that is wrong. Do I need to specify another namespace or shouldn't it default to it anyway? Is there a Project setting for this?
TIA
|
|
|
|
|
i could be way off here, but are you sure you're supposed to have the .h in the filename for the include?
i mean, like
#include <iostream>
as opposed to <iostream.h>
just something to try if you havne't already
~L
|
|
|
|
|
I believe that I read somewhere that leaving the .h off of the header file for the #include means that you'll use the new C++ runtime library while using the .h means you're using the older version.
I think I may have found the problem...all of those errors I was getting occured in the header files, iostream.h and iomanip.h....I found this at the top:
#if !defined(_WIN32) && !defined(_MAC)
#error ERROR: Only Mac or Win32 targets supported!
#endif
So, it looks like I need to make this a true Win32 project though I am already using a Win32 console application. Hmmmm.
|
|
|
|
|
You aren't getting that error so that isn't the problem.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
JohnnyG wrote:
I believe that I read somewhere that leaving the .h off of the header file for the #include means that you'll use the new C++ runtime library while using the .h means you're using the older version.
That is right - the old one does not use namespaces. If you include both in different parts of a project, and use namespace std in it's entirety, then you'll have that namespace collision because you've loaded the same library twice, once with and once without namespace protection, but then using namespace std; blows it away.
You should NEVER use iostream.h or any other .h header where the name alone ( #include iostream for example ) works. you should only put using statements for what you use, using std::ifstream for example.
JohnnyG wrote:
So, it looks like I need to make this a true Win32 project though I am already using a Win32 console application. Hmmmm.
Bollocks. I use iostream constantly, in Win32, in MFC and in ATL. I think you got the header right somewhere and wrong somewhere else. Make sure you only include the non .h headers, and do it in stdafx.h if possible. Put using statements only for the things you use. Then let me know if you still have the problem.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
And you don't spend much time with the opposite sex working day and night, unless the pizza delivery person happens to be young, cute, single and female. I can assure you, I've consumed more than a programmer's allotment of pizza, and these conditions have never aligned. - Christopher Duncan - 18/04/2002
|
|
|
|
|
Thanks!! I got it working. Took your advice about including "stdafx.h" and used the using keyword sparingly as needed.
|
|
|
|
|
Great - glad I could help.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
And you don't spend much time with the opposite sex working day and night, unless the pizza delivery person happens to be young, cute, single and female. I can assure you, I've consumed more than a programmer's allotment of pizza, and these conditions have never aligned. - Christopher Duncan - 18/04/2002
|
|
|
|
|
Hello,
My visual studio just crashed on a compile and when I re-opened the project it says unable to load class information. class view information file could not be opened, or something like that.. How do I get the class view info back?
Thanks
|
|
|
|
|
In your project folder, there is a file named *.clw (this is the class view file). Simply rename it to something like *_bak.clw (to have something backup). Then in your VC++ 6.0, press Ctrl+W, it will ask you whether should rebuild the class information. Answer yes and you'll get your class view back.
Good luck!
|
|
|
|
|
I tried that first  and for some reason it still isn't loading the class info.. weird.. I'll do some more playing. If you can think of anything else please let me know.
Thanks
|
|
|
|
|
have you added every file in your project to build the *.clw?
|
|
|
|
|
do you have two copies of the same workspace open in two different VS instances?
-c
"Should you not have a ramekin of sea salt beside the stove, you don’t deserve oatmeal."
Dean Allen
|
|
|
|
|
Are you referring to the tree view of the classes and methods, or the ClassView wizard. The .clw file is used by the wizard. I believe the one used for the explorer bar is .ncb.
Good Luck,
Bill
|
|
|
|
|
This is one of the most annoying bugs in VC6. When the IDE crashes like this, it leaves MSDEV running. This means when you open the studio again it thinks there are two copies running, the crashed one still has the NCB file open. You'll have to close your open copy and then use task manager to kill the msdev.exe process. Then you should be able to reopen your project.
Michael 
|
|
|
|
|
I have this app where i need to retrieve some settings from the registry, here's my code:
DWORD dwDisposition;
LPCTSTR SubKey = "SOFTWARE\\MP3Reader";
DWORD KeyLen = 0;
HKEY OpenKey;
DWORD DataType = REG_SZ;
DWORD DataLen;
char Data[MAX_PATH+1];
RegCreateKeyEx(HKEY_CURRENT_USER, SubKey, 0, NULL, 0, KEY_READ, NULL, &OpenKey, &dwDisposition);
if (dwDisposition == REG_OPENED_EXISTING_KEY)
{
RegEnumValue (OpenKey, 0, KeyValue, &KeyLen, NULL, &DataType, (unsigned char *)Data, &DataLen);
SetDlgItemText (hWnd, IDC_FILEPATH, (LPCTSTR)Data);
}
RegCloseKey (OpenKey);
<pre>
When it comes to the RegCloseKey sentence the following error appears:
Link: http:
I don't understand it cause the Registry handle (OpenKey) is used in RegEnumValue and there it works fine cuase it retrieves the value and fills up the Data variable with the correct data, but when it reaches to that specific sentence it doesen't work even though the variable hasn't been manipulated.
Thanks for the help!
|
|
|
|
|
You first must to open the RegKey with RegOpenKeyEx. The last parameter will return you the Handle of the opened key, that you must to use in RegCloseKey 
Bets Regards
Carlos Antollini.
www.wanakostudios.com
Sonork ID 100.10529 cantollini
|
|
|
|
|
The RegCreateKeyEx function will, if the registry key already exist, open the existing key and return it in the 8th parameter:
LONG RegCreateKeyEx(
HKEY hKey,
LPCTSTR lpSubKey,
DWORD Reserved,
LPTSTR lpClass,
DWORD dwOptions,
REGSAM samDesired,
LPSECURITY_ATTRIBUTES lpSecurityAttributes,
PHKEY phkResult,
LPDWORD lpdwDisposition
);
And i also tried it before where it worked, i don't know why it doesen't work now...
|
|
|
|
|
Try checing the error codes on all the calls. Make sure they are returning 0s.
Good Luck,
Bill
|
|
|
|
|
Check if RegCreateKeyEx returns ERROR_SUCCESS and close the key only if it is successful.
if (RegCreateKeyEx(...) == ERROR_SUCCESS)
{
// your code here
RegCloseKey(...);
}
Like it or not, I'm right.
|
|
|
|
|
is there some mysterious unwritten law against inheriting INDIRECTLY from MFC classes?
i'm having all sorts of trouble trying to do something very simple. here is an example of my woe:
I'd like to create my own Wizard property sheet class, derived from CPropertySheet. ok, well- that's all fine and good, as long as I use the class that inherits directly from CPropertySheet. but try to add another layer, and forget it. will NOT compile.
same thing now happening with CPropertyPage. I'm trying to make a bunch of pages for my wizard, and they share common characteristics. seems like the textbook case of where to use a base class. I'd like to make my base class, WizardPage (or whatever) inherit from CPropertyPage. then all of my actual pages inherit from WizardPage.
no matter what i try, this will not compile. if i try to use one of the child classes, it says "base class undefined" or something. trust me, i included the right headers.
i would be forever grateful to anyone who can explain why this is happening.
~L
|
|
|
|
|
There is nothing wrong with what you are trying to do. There is no limitation of inheritance from MFC classes or CPropertySheet.
Sorry, but the problem is in your code.
here is a sample:
[ccode]
// Derived.cpp: implementation of the CDerived class.
//
//////////////////////////////////////////////////////////////////////
#include "stdafx.h"
#include "RegHelper.h"
#include "Derived.h"
#include "MyPropSheet.h"
#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif
//////////////////////////////////////////////////////////////////////
// Construction/Destruction
//////////////////////////////////////////////////////////////////////
CDerived::~CDerived()
{
}
CDerived::CDerived(UINT nIDCaption, CWnd* pParentWnd, UINT iSelectPage)
:CMyPropSheet(nIDCaption, pParentWnd, iSelectPage)
{
}
/////////////////////////////////////////////////////////////////////////////
// CMyPropSheet
class CMyPropSheet : public CPropertySheet
{
DECLARE_DYNAMIC(CMyPropSheet)
// Construction
public:
CMyPropSheet(UINT nIDCaption, CWnd* pParentWnd = NULL, UINT iSelectPage = 0);
CMyPropSheet(LPCTSTR pszCaption, CWnd* pParentWnd = NULL, UINT iSelectPage = 0);
// Attributes
public:
// Operations
public:
// Overrides
// ClassWizard generated virtual function overrides
//{{AFX_VIRTUAL(CMyPropSheet)
//}}AFX_VIRTUAL
// Implementation
public:
virtual ~CMyPropSheet();
// Generated message map functions
protected:
//{{AFX_MSG(CMyPropSheet)
// NOTE - the ClassWizard will add and remove member functions here.
//}}AFX_MSG
DECLARE_MESSAGE_MAP()
};
[/ccode]
Hope this helps,
Bill
|
|
|
|
|
thanx for the response. i did in fact find the problem not too long after i posted the question.
the main thing i've found is that you have to be really careful about the Class Wizard. it's helpful, but only up to a point. (like, up to the point where you add another level of inheritance to your class heirarchy- eg, if i were to make a class inherit from your CMyPropSheet)
anywyas, thanx again for taking hte time to help out.
~L (spoongirl)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
