|
Last question. Before the statement does it have to be declared?
|
|
|
|
|
I am not sure I understand your question. However, all variables must be declared/defined before use. If you use a variable without declaring it, the compiler will generate a compiler error.
Bob
|
|
|
|
|
I'm sorry for being confusing. Does the assignment statement goes in as a statement like:
//weekly wages = 12.75*40 + ( (40>40) ? (12.75*40/2) : 0 );
modified on Thursday, October 16, 2008 8:53 PM
|
|
|
|
|
It depends on exactly what you want to compute, however, in a word, No. If Weekly wages is suppose to be a variable then you are not allowed to have spaces in the variable.
I get the impression that I am not helping you. I think you need to find a basic tutorail on C or C++ and read it.
Bob
|
|
|
|
|
Bob you helped me out alot. I have a better understanding of what I was doing wrong. Thanks for the help.
|
|
|
|
|
Hi,
I am using API RegEnumValue() to retrieve the regkey's values. However, for DWORD and BINARY datatype it returns some garbage or junk characters in buffer(for the values which has above datatypes).. do I need to typecast this returned data to make it readable in eng ??? if yes how shud I do that, any pointers ?
Thanks in advance.
Regards,
Supriya Tonape
|
|
|
|
|
Please give us an example of the input (i.e. the registry key type & value), the code you're using and the output you're getting.
BTW ALL the info inside any PC has to be translated in some manner in order to read it as English.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The Registry Key Value Type is 'REG_DWORD' and 'REG_BINARY'.
You can create any new key in registry and then create new key values for it which has datatype as above(Selecting 'DWORD Value' and 'BINARY Value') and plz have a look at datavalue to see how data looks like.. For 'REG_SZ' values I am getting data in buffer properly.
Sample Code : (Assume regkey handle and open proc is passing and I am able to access it thru another APIs)
// Enumerate the key values.
if (dwValues)
{
.
.
for (i=0, retCode=ERROR_SUCCESS; i<dwvalues;>
{
.
.
retCode = RegEnumValue(
hkScanKey, // Handle to an open registry key
i, // The index of the value to be retrieved
pszRegValueName, // Pointer to a buffer that receives the name of the value
&dwRegValNameLen, // Size of the buffer pointed to by the 'pszRegValueName'
NULL, // Reserved
&dwRegValType, // Type of data
(LPBYTE)pszRegValData, // Data for the value
&dwRegValLen); // Size of Data
.
.
}
}
so whenever it finds any value with datatype 'REG_DWORD' or 'REG_BINARY' , the buffer 'pszRegValData' has some garbage value or unreadble val...
Regards,
Supriya Tonape
|
|
|
|
|
Are you aware that RegEnumValue returns a 32 bit integer whenever it finds a REG_DWORD ? It doesn't return the string representation of the number. The same applies to REG_BINARY . Of course I'm only guessing, since you missed posting input & output value samples.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
RegEnumValue returns data in 'BYTE' in one of the OUT parameters and yes it does return the LONG value for the function call.
I am talking about 'lpData' param in below structure.
LONG WINAPI RegEnumValue(
__in HKEY hKey,
__in DWORD dwIndex,
__out LPTSTR lpValueName,
__inout LPDWORD lpcchValueName,
__reserved LPDWORD lpReserved,
__out_opt LPDWORD lpType,
__out_opt LPBYTE lpData,
__inout_opt LPDWORD lpcbData
);
when I iterate thru different values of regkey I get below outputs:
'REG_DWORD' Data : "94f"
lpData = ''
(For 'REG_SZ' datatype its does return proper output)
'REG_SZ' Data : "|386|ADE|ADP"
lpData = '|386|ADE|ADP'
Regards,
Supriya Tonape
|
|
|
|
|
Supriya Tonape wrote: 'REG_DWORD' Data : "94f"
lpData = ''
In the above circumstance, with
DWORD dwValue = *((DWORD *) lpData);
what is the value of dwValue ?
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thank you so much! it did help and I didnt want REG_BINARY conversion anymore but yes for REG_DWORD your help is much appreciated !
Regards,
Supriya Tonape
|
|
|
|
|
You're welcome.
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I am new to this. I have made an activex edit control that deals only with floating point numbers. It works perfect in the test container, but I cannot get it to work at all in my application. After inserting it the software added the class to my project. It compiles without error or warning, but I cannot update data to the control or read anything frrom it into my application. Any advice would be appreciated.
Thanks
|
|
|
|
|
Just because there wasn't a clear / working link to an old MSDN article that got archived, rewritten, and (insert w/e they do at m$ web oversight here),
http://msdn.microsoft.com/en-us/library/kdzttdcb.aspx[^]
WaitForSingleObject works with beginthreadex because it doesn't close its own handle
|
|
|
|
|
Indeed!
There's several differences described in the current docs[^]
(see the Remarks section).
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Below is what is suppose to be a valid but minimal MFC Application using SDI. It consists of
two files, the first is a header file, the second is a C++ file.
Header File
#define IDR_MAINFRAME 100
class MainApp : public CWinApp {
public:
virtual BOOL InitInstance();
};
C++ File
#include <afxwin.h>
#include "Main.h"
#define OEMRESOURCE
MainApp myApp;
class MyDocument : public CDocument {
DECLARE_DYNCREATE( MyDocument )
};
IMPLEMENT_DYNCREATE( MyDocument, CDocument )
class MyView : public CView {
DECLARE_DYNCREATE( MyView )
protected:
void OnDraw(CDC *);
};
IMPLEMENT_DYNCREATE( MyView, CView )
void
MyView::OnDraw(CDC *pDC)
{
}
BOOL
MainApp::InitInstance ()
{
SetRegistryKey (TEXT("Programming Windows 95 with MFC"));
LoadStdProfileSettings ();
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate (
IDR_MAINFRAME,
RUNTIME_CLASS (CDocument),
RUNTIME_CLASS (CFrameWnd),
RUNTIME_CLASS (MyView)
);
AddDocTemplate (pDocTemplate);
RegisterShellFileTypes (TRUE);
CCommandLineInfo cmdInfo;
ParseCommandLine (cmdInfo);
if (!ProcessShellCommand (cmdInfo))
return FALSE;
m_pMainWnd->DragAcceptFiles ();
return TRUE;
}
However, when I compile and run it, it dies in the call to DragAcceptFiles. I do not understand why. I am hoping that somebody here can tell me what is wrong, or the best way to debug this program.
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: it dies in the call to DragAcceptFiles
Hello Bob, when you are experiencing errors saying things like "it doesn't work","it breaks","it dies" is not appropriate. You need to post actual error information. GetLastError() numbers, Exception text, assert information like the line of code containing the assert, etc. Hopefully you get the idea.
BobInNJ wrote: or the best way to debug this program.
I don't know what that means. Debugging is somewhat universal, you break into the execution at a line of code and analyze the state of the process using debugger tools (call stack, memory values).
Also, in case you are trying to implement drop files without a net maybe this will help.[^]
led mike
|
|
|
|
|
 Mike,
Thank you for the response. The error message I get is in the form of a Error Box. The title
of the Box says Microsoft Visaul C++ Debug Library". It also has the line Debug Assertion Failed!. The box also has button on it for Abort, Retry and Ignore.
It gets to the statement:
if (!ProcessShellCommand (cmdInfo))
but it does not get to the statement:
m_pMainWnd->DragAcceptFiles ();
Therefore, I step into the routine ProcessShellCommand. Here is the call stack for the
program after it dies:
> sdi1.exe!AfxMessageBox(unsigned int nIDPrompt=61700, unsigned int nType=0, unsigned int nIDHelp=4294967295) Line 163 + 0x17 bytes C++
sdi1.exe!CSingleDocTemplate::OpenDocumentFile(const wchar_t * lpszPathName=0x00000000, int bMakeVisible=1) Line 113 C++
sdi1.exe!CDocManager::OnFileNew() Line 848 C++
sdi1.exe!CWinApp::OnFileNew() Line 22 C++
sdi1.exe!CWinApp::ProcessShellCommand(CCommandLineInfo & rCmdInfo={...}) Line 26 C++
sdi1.exe!MainApp::InitInstance() Line 46 + 0xc bytes C++
sdi1.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020908, int nCmdShow=1) Line 37 + 0xd bytes C++
sdi1.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020908, int nCmdShow=1) Line 30 C++
sdi1.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
sdi1.exe!wWinMainCRTStartup() Line 182 C
kernel32.dll!7c817067()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
Also, it would seem to me that this is a very simple MFC program and that for somebody who understands MFC should be able to tell me what is wrong off the top of his (or her) head. Maybe, I am wrong about this. My limited experience with MFC SDI programs is that they are full of unexpected surprises.
Thanks
Bob
|
|
|
|
|
In addition to led mike's reply...
You have not created a window anywhere and haven't set m_pMainWnd
to anything so m_pMainWnd->DragAcceptFiles() is certainly going to fail.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark,
Thanks for the response. First, the program never reaches the statement:
m_pMainWnd->DragAcceptedFiles();
Therefore, I do not think that me not setting m_pMainWnd is the problem. Second, my program
is based upon the program in Chapter 8 for Jeff Prosise book, "Programming Windows 95 with MFC" the first edition. In his program, which I could not get to work either, he did not set m_pMainWnd. It is my understanding (which might be all wrong) that when I call the constructor (via new) of CSingleDocTemplate then the window is created automatically and the pointer m_pMainWnd is set. Am I wrong about this?
Also, please look at my last post to see a more detailed explanation on how my program bombs out.
Thanks
Bob
|
|
|
|
|
BobInNJ wrote: the program never reaches the statement:
m_pMainWnd->DragAcceptedFiles();
But you originally stated "it dies in the call to DragAcceptFiles"
BobInNJ wrote: when I call the constructor (via new) of CSingleDocTemplate then the window is created automatically and the pointer m_pMainWnd is set
Son of a gun, you're right.
Maybe put a breakpoint at the beginning of CSingleDocTemplate::OpenDocumentFile()
and step through - what line of code in there is asserting?
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark,
Thanks for the prompt response.I do nto remeber saying that it dies in DragAcceptFiles. If I did, I was wrong. Sorry about that. In any case, here is a partial listing of the routine it dies in.
<br />
CDocument* CSingleDocTemplate::OpenDocumentFile(LPCTSTR lpszPathName,<br />
BOOL bMakeVisible)<br />
{<br />
CDocument* pDocument = NULL;<br />
CFrameWnd* pFrame = NULL;<br />
BOOL bCreated = FALSE;
BOOL bWasModified = FALSE;<br />
<br />
if (m_pOnlyDoc != NULL)<br />
{<br />
pDocument = m_pOnlyDoc;<br />
if (!pDocument->SaveModified())<br />
return NULL;
<br />
pFrame = (CFrameWnd*)AfxGetMainWnd();<br />
ASSERT(pFrame != NULL);<br />
ASSERT_KINDOF(CFrameWnd, pFrame);<br />
ASSERT_VALID(pFrame);<br />
}<br />
else<br />
{<br />
pDocument = CreateNewDocument();<br />
ASSERT(pFrame == NULL);
bCreated = TRUE;<br />
}<br />
<br />
if (pDocument == NULL)<br />
{<br />
AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);<br />
return NULL;<br />
}<br />
ASSERT(pDocument == m_pOnlyDoc);<br />
The statement that is gennerating the message box is:
AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);
I am thinking that CreateNewDocument should not be returning NULL but it is.
Thanks
Bob
|
|
|
|
|
|
Mark,
Thanks for the response. The place it is dying in is:
if (pDocument == NULL)
{
AfxMessageBox(AFX_IDP_FAILED_TO_CREATE_DOC);
return NULL;
}
ASSERT(pDocument == m_pOnlyDoc);
That is, pDocument is NULL so the body of the if statment is entered and the call to AfxMessageBox happens. I hope this is clear.
Bob
|
|
|
|