|
Or the only way is create a pointer to do it
me think yes.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Isn't a pointer just a long integer anyways? I didn't try this, but I don't see a reason why a long int couldn't hold an address...it doesn't care if it's an address...as long as it is a value which matches its type.
I don't know why you'd do this though...that's what pointers are for...
|
|
|
|
|
This will break 64 bit code (AMD64) where pointers are 64 bits and integers are 32 bits.
John
|
|
|
|
|
I believe you could use references for this:
int a = 5;
int &b = a;
a = 500; //now a == 500 AND b == 500
b = 1234; //now a == 1234 AND b == 1234
I'm not totally sure that's right though, you should probably step through the code in a debugger and check.
Hope that helps,
Pete
|
|
|
|
|
I stand corrected, forgot about references.
int a = 5;
int &b = a;
in that case, &a == &b ( the address of a and b are the same).
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Thanks. I totally forgot about that one 
How would I go about so b's memory address would point to a's memory address?
class CFirst(){
private:
int a;
public:
CFirst(){ a = 25; };
int ReturnA(){ return(a); };
};
class CSecond(){
private
int b;
};
int main(){
CFirst a;
return 0;
}
The stuff I am doing is a little bit more complex. I want to point b's link list data to a's link list's data and then remove the la ink list(without destroying the data)
|
|
|
|
|
You know, you really should join up and sign in if you want people to help you out Membership is the key...
Anyway, something along these lines might point you in the right direction:
class CFirst
{
...
...
public:
int &GetReferenceToA()
{ return a; }
...
...
}
class CSecond
{
public:
class CSecond( int &numberToAttachTo )
: b( numberToAttachTo )
{}
protected:
int &b;
};
int main()
{
CFirst instanceOfFirst;
CSecond instanceOfSecond( instanceOfFirst.GetReferenceToA() );
...
...
}
I don't know how much that helps. There would be quite a few ways of initializing the 'connection' between a and b.
One thing to note is that any member variables of CSecond() that are references MUST be initailized at construction time. This makes them more fiddly to use than pointers, IMHO.
HTH,
Pete
|
|
|
|
|
The stuff I am doing is a little bit more complex. I want to point b's link list data to a's link list's data and then remove the la ink list(without destroying the data)
you can't really do that, at least the way I think you want to do it.
if your data ( a or b ) are not dynamically allocated ( new or malloc ) , then, you will need to copy the data; and passing a reference a to b and then removing a will invalidate b ( at best ).
in your example, ReturnA copies the data.
but for example, if your CFirst looks like :
class CFirst {
int* a; // will be allocated and assigned.
int* ReturnA( return a;};
}
then, you return the address of a to whoever receives it;
int* b = ReturnA();
but you will need to keep track of allocation and deallocation.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
I have an account I just keep forgetting to log in.
int* ReturnA(){ return a;};
doesn't work.
I have been trying to get function to return pointer
Nevermind I am an idiot. Forgot to add () when I call the function 
You can't assign &b on the fly right? Only at the intitalization.
|
|
|
|
|
You could create a 'reference'. A reference variable is somewhat like a mix between a pointer and a copy variable. References are much like synonymes with same type.
For example:
int A = 5;
int& B = A; Now both &A and &B operations return the same value, A's address. If A is changed, B changes, and vice versa. In syntactical terms, however, they are the same thing. Same thing (an integer variable) with two seperate names.
-Antti Keskinen
----------------------------------------------
"If we wrote a report stating we saw a jet fighter with a howitzer, who's going to believe us ?"
-- R.A.F. pilot quote on seeing a Me 262 armed with a 50mm Mauser cannon.
|
|
|
|
|
I only saw part of the other answers! But...
-----------------------------------------------------------------------------
int A = 5; // declared and intialized
int *pB = &A; // ponter to int declared and intialized to address of A
// pB is an inderect reference to A, which means it holds the address of A
// &A is the address of A (aka. indirect reference)
// *pB is a dereferncenced pointer (aka. direct reference)
int &C = A; // direct reference declared and intialized
// C and A are both references to the same data (memory location)
// Therefor, &A = pB = &C and A = *pB = C.
-----------------------------------------------------------------------------
Thats it, in a nut shell.
-----------------------------------------------------------------------------
It seems complicated, don't it. Given time it will become second nature to you.
-----------------------------------------------------------------------------
This might help:
#include <stdio.h>
int main(void)
{
int A = 5;
int *pB = &A;
int &rC = A;
prinf(
"Address of A = %p, Value of A = %d\n"
"Address of pB = %p, Address stored in pB = %p, Value of *pB = %d\n"
"Address of rC = %p, Value of rC = %d\n",
&A, A,
&pB, pB, *pB,
&rC, rC);
return 0;
}
I have not tested the code above, but is should give you an idea of the relationships between pointers and references.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
can we create a rich colored icon - i.e. 256 colors or more - for VC?
includeh10
|
|
|
|
|
hi,
you can, but not with resource editor supplied with VC.
GSte
|
|
|
|
|
Is it possible to use the standard CFileDialog, and dynamically hide certain controls before it is displayed? I am able to create a hook function to trap the WM_NOTIFY/CDN_INITDONE message sequence, but cannot seem to grab the handles for the controls on the dialog at this stage. Can anyone enlighten me?
I've tried several different versions of the following code, to no avail. What am I doing wrong?
CString CCustomizedDialog::GetFolder()
{
OPENFILENAME ofn;
memset(&ofn, 0, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = NULL; //or any valid parent window handle.
ofn.hInstance = AfxGetInstanceHandle(); //or your hinstance variable if you are not using mfc support.
ofn.lpstrFilter = _T("Text Files\0*.txt\0\0"); //modify this for any other filter.
ofn.lpstrCustomFilter = NULL;
ofn.nFilterIndex = 0;
ofn.lpstrFile = new TCHAR[256];
memset(ofn.lpstrFile, 0, 256 * sizeof(TCHAR));
ofn.nMaxFile = 256;
ofn.lpstrFileTitle = NULL;
ofn.lpstrInitialDir = NULL;
ofn.lpstrTitle = NULL;
ofn.Flags = OFN_EXPLORER | OFN_ENABLEHOOK | OFN_ENABLETEMPLATE;
ofn.lpfnHook = OFNHookProc; //Custom hook procedure.
ofn.lpTemplateName = MAKEINTRESOURCE(FILEOPENORD);
GetOpenFileName(&ofn);
CString theReturnString = ofn.lpstrFile;
delete [] ofn.lpstrFile;
return theReturnString;
}
//Custom hook procedure stub. Must remain outside of the class
UINT CALLBACK OFNHookProc(
HWND hdlg, // handle to child dialog box
UINT uiMsg, // message identifier
WPARAM wParam, // message parameter
LPARAM lParam // message parameter
)
{
// set a flag so we know when the dialog has been initialized
static BOOL isInitialized;
CEdit* theEditBox;
//Do your message processing here.
//Return 0 if you need the default dialog box procedure to process
switch (uiMsg)
case WM_NOTIFY:
{
AfxMessageBox("Notify was caught!");
if(isInitialized == TRUE)
{
HWND theParent = GetParent(hdlg);
if(theParent != NULL)
{
theEditBox = (CEdit*)GetDlgItem(theParent,edt1);
theEditBox->SetWindowText(_T("Readme.txt"));
}
}
/// catch CDN_INITDONE message so we can
/// change the look of the dialog
if(((OFNOTIFY *)lParam)->hdr.code == CDN_INITDONE)
{
AfxMessageBox("INITDONE was caught!");
isInitialized = true;
HWND theDlg = GetParent(hdlg);
CString theMsg = "The ParentHWND: ";
// theMsg += theDlg;
// AfxMessageBox();
}
}
return 0;
}
Thanks,
--Mark
|
|
|
|
|
You might consider using Spy++ to display the dialog and then get info on the control in question - this will give you the control's ID, which you could then use with the GetDlgItem() call, passing in the ID that Spy++ discovered.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Hi Jim,
Thanks for the quick reply. I think the problem is with getting a handle to the actual dialog on which the control is drawn. I have to pass this handle (I believe) to the GetDltItem() function. I have tried both the hdlg parameter, and GetParent(hdlg) in the hook function, but neither one seems to work. I have been looking at Spy++, and the handle I get for the actual dialog does not match either one of these...
I will look at it again, though. Thanks.
|
|
|
|
|
Since you're using MFC (or it appears so), it might be a little easier if you subclass CFileDialog and overload it's OnInitDialog member function. In the subclass OnInitDialog function, you can use GetDlgItem(), using the control IDs that you obtain using Spy++, to get pointers to the dialog controls you want to hide.
If you do this way, you won't need a special dialog proc and you won't have to deal with the OPENFILENAME structure.
|
|
|
|
|
Yes, thank you. I had originally tried doing this, but was unable to get handles to the controls on the dialog. I was using the constants defined in dlgs.h (edt1) to grab handles (GetDlgItem()). Are these constants not correct? I'm confused as to why I would need to use spy++ to get the ids...are they not constant?
Thanks for all the help.
|
|
|
|
|
Okay, I tried this, and there are two problems (unless I'm doing something wrong). The first is, spy++ gives me handles to windows, not control id's. The second is, these handles are not constant...they are different each time I bring up the dialog box.
|
|
|
|
|
Yes, you are correct, the window handles will most likely be different each time the dialog comes up. Here's a step by step in Spy++ to get the info you need.
1. Bring up the common dialog having the control you want to hide. Do this before you run Spy++.
2. Run Spy++ and press Alt-F3 (Search for window).
3. On the Find Window, there's a crosshair icon, grab it and drag to the control on the common dialog you want info about. If you need to, you can check the "Hide Spy++" checkbox to get Spy++ out of the way. This will show the Handle and class name. Sounds like you got this far.
4. Now, click on the Ok button on the Find window dialog (in Spy++). The window you're wanting info about should now be selected in the tree view on the "Windows 1" view.
5. Right click on the highlighted item in the tree and select properties. This will bring up another dialog with the information that you need, namely the control ID.
Note that the Control ID is displayed in hex.
Given the Control ID, you can do something like this in your subclass OnInitDialog (example hides the Cancel button):
CWnd* pCancelBtn = GetDlgItem(0x0002);
if (pCancelBtn != NULL)
pCancelBtn->ShowWindow(SW_HIDE);
|
|
|
|
|
Thank you so much for the help. You've lead me in the right direction. The problem was in calling the GetDltItem...I needed to call that for the parent window:
CWnd *theParentWnd = this->GetParent();
CWnd *theEditBox;
// edt1 is defined in <dlgs.h>
theEditBox = theParentWnd->GetDlgItem(edt1);
theEditBox->ShowWindow(SW_HIDE);
This worked! By the way, the ID in spy++ matched that defined in dlgs.h, so I just used it.
Thanks again...whew, what a workout!
|
|
|
|
|
I seem to be running afoul of the TaskManager in some way that I am unaware of.
In the VCF we have the core GUI library that contains an .ICO file that's used in the WNDCLASSEXW struct before calling RegisterClassExW().
I fill it in like so:
WNDCLASSEXW wcex;
wcex.cbSize = sizeof(wcex);
wcex.style = CS_HREDRAW | CS_VREDRAW | CS_DBLCLKS;
wcex.lpfnWndProc = (WNDPROC)wndProc;
wcex.cbClsExtra = 0;
wcex.cbWndExtra = 0;
wcex.hInstance = (HINSTANCE)::GetModuleHandle(NULL);
wcex.hIcon = LoadIconW( Win32ToolKit::getInstanceHandle(), L"DefaultVCFIcon" );
wcex.hCursor= NULL;
wcex.hbrBackground = (HBRUSH)(COLOR_WINDOW+1);
wcex.lpszMenuName = NULL;
wcex.lpszClassName = className.c_str();
wcex.hIconSm = NULL;
This works fine. But sometimes when I call up the TaskManager there is no entry for the executable!. Using Alt+Tab, the window icon is there just fine.
It shows in the task bar just fine.
If I change the window icon dynamically by calling
HICON winIcon = //get the HICON image
SetClassLong (hwnd_, GCL_HICON, (LONG)winIcon);
Is this incorrect? Using WM_SETICON seemed to have problems as well.
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Hello:
I needed to have an Animated Gif in my program so I included the code from PictureEx which works great except for the following.
I complie using Level 4 which means I get a lot of warnings.
Since including the code from PictureEx I now get 35 warnings for C4663, C4018 and C4100 these all refer to where he is using a Vector template class.
I tried using #pragma warning( disable : 4018 4100 4663 ) but this doesn't help. Tried all forms of this #pragrma and still can't get rid of these warnings.
I never have warnings in my code and can't figure out how to get rid of these that the PictureEx code has caused.
Can anyone help
Thanks
BobVal
|
|
|
|
|
C4663 is caused by an old template class declaration. It is not an actual error, and should not cause errorneous behaviour, but when time goes on and new compilers appear, this declaration form will soon become a syntactical error. The creator of the class should alter the original source code to fix this. You can do nothing (besides directly modifying the source code) to fix it. If the source code license allows it, feel free to do it and post a corrected version to the author.
C4018 is caused by signed/unsigned comparison mismatch. This originally inherits from the way signed and unsigned numbers are handled. In assembly/machine-code, the concept of signed/unsigned does not exist. All numbers are unsigned there. The difference is made by interpreting the value. Consider an 8-bit value (such as a 'char'). If it is a signed char, direct values 0-127 refer to signed values 1...127 and values 128-255 refer to -128...0. It cannot have a value outside of range -128...127. A comparison operation in assembly is a mathematical substraction. If the substraction causes a 'borrow' to happen (don't know the actual math term in english for it), a flag is set. Looking at this flag, the conclusion of greater or not is made, and true/false is returned. It is possible that sometimes, when the numbers are suitable, an errorneous interpretation is made. I cannot outright remember what these conditions are. Lets just say that avoid comparing unsigned and signed numbers whenever possible
C4100 is caused by having an unreferenced parameter in function declaration. This is like having a needed parameter passed to a function and the parameter is never used inside the function, making it irrelevant for the function. It is most obviously a typing error in the source code. Fixing it requires checking the function in question and seeing if a parameter truly is unreferenced, and if it is, removing it from the function definition. Again, a source code change is necessary.
In conclusion, there's nothing you can do to fix these errors without altering the PictureEx source code. But none of them are critical, either, excluding the first one. C4663 might cause an error later on when a new compiler is released that no longer supports the old-style syntax.
Hope this helps.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
THIS WAS ZERO HELP
I KNEW THESE ARE WARNINGS, I Stated this.
I know what the messages mean, I looked them up.
I WANT TO STOP the compiler from generating these warnings.
With the exception of this PictureEx code I have ZERO warnings when I compile my programs. I don't want to fix Microsoft's Vector template class and I don't know how to fix the PictureEx code to get rid of this warnings.
So I have been trying to get the complier to NOT DISPLAY them or IGNORE them when compiling the code.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
