|
Not the way you wrote this. Actually, by C99 standard this is possible, but VC does not support it (yet?).
Instead, you can use std::vector, which is much more flexible and easy to use. Or you can write
int* arrayvalue = new int[size];
and call
delete[] arrayvalue;
when you finish. However, I suggest vector.
I vote pro drink ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
im a newbie myself, but i have been using CStringArray, CObArray, and CUIntArray. These are build in classes for arrays of different types. They are cool because you can add and delete them without caring about what the size is. example:
// add stuff to it
CStringArray strArray;
CString strTemp("Hello");
strArray.Add(strTemp);
strTemp = "Second string";
strArray.Add(strTemp);
// get stuff from it
strTemp = strArray.GetAt(0);
strTemp += strArray.GetAt(1);
// delete an unwanted string
CString* pStr = strArray.GetAt(0);
delete pStr;
strArray.Remove(0);
keep in mind that these are arrays of pointers which point to strings, or objects, etc.
-dz
|
|
|
|
|
Might I recommend that you look into the stl:vector as recommended above ? Much better than lousy MFC container classes, which were only ever a stopgap while the STL was on it's way.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Hi,
Does anyone know how to create a global variable so that all classes in the project can share.
For example, i need this global variable:
int temp;
No matter which class I'm currently, i just use it as normal:
temp = temp + 1; (nothing liked.......... XXXX.temp = XXXX.temp + 1
I know I need to create a file to store all those global variable...but i forgot how to do it.
Anyone can help?????
|
|
|
|
|
Declare teh variable in a header and include that header in all clases, or declare that variable in the App class and you can get the class using AfxGetApp() for get a pointer to CWinApp class
best Regards
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
If you are not using MFC, then declare the variable in stdafx.cpp like you want it.
This block has been added to the original message to clarify some confusion.
My response was after Carlos' which was a response for MFC, his response was on the thread before this one. I added the statement about MFC just in to clarify that if the person who posted the question was not using MFC and could not use the CWinApp object. The technique that I posted will work for any type of C++ project.
int g_Temp;
Then you will need to declare it in stdafx.h like this:
extern int g_Temp;
The extern tells each file that it is included in to add the g_Temp variable to the symbol table so that the variable can be used, but does not actually allocate space for that variable in the obj file. Then when the linker comes around it will resolve all of the variable locations and what not.
If you do not use the extern keyword, and you declare the variable in the header, then your program will allocate space for each file that the variable was declared in, and when the linker tries to resolve all of the variable addresses, it will find collisions.
|
|
|
|
|
|
Well you beat me to the MFC solution, so we'll call it even  .
|
|
|
|
|
kilowatt wrote:
If you are not using MFC,
What does MFC have to do with it ? I do this in MFC apps all the time.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
Christian Graus wrote:
What does MFC have to do with it ? I do this in MFC apps all the time.
I simply added this just in case the person who posted the question was not using MFC and did not have access to the CWinApp class inside of their program.
Tomasz Carlos Antollini post on the thread before this thread stated this:
Declare teh variable in a header and include that header in all clases, or declare that variable in the App class and you can get the class using AfxGetApp() for get a pointer to CWinApp class
Of course this method that I mentioned is possible in both an MFC and non-MFC apps alike.
|
|
|
|
|
kilowatt wrote:
Tomasz post on the thread before this thread stated this:
Declare teh variable in a header and include that header in all clases, or declare that variable in the App class and you can get the class using AfxGetApp() for get a pointer to CWinApp class
It was Carlos' post, actually. 
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I see - that you were replying to a previous reply was not clear to me.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
|
|
|
|
|
This technique will work on any type of project that has the two files named. It does not have anything to do with MFC. If you don't have files by that name, put the extern in every module where you reference the global. Put the definition in any .cpp file in your project.
,
Bill
|
|
|
|
|
This technique will work on any type of project that has the two files named. It does not have anything to do with MFC. If you don't have files by that name, put the extern in every module where you reference the global. Put the definition in any .cpp file in your project.
|
|
|
|
|
If you insist on global variable (I'm leaving discussion about their value for later time), you need to do two things:
extern int g_Temp;
int g_Temp = 0;
To access g_Temp just #include appropriate header
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
For some time I'm trying to draw the caption of a dialog myself, including the buttons and the line that seperates the NC area and the Client area.
Kilowatt adviced me to add SetWindowLong to the WM_NCACTIVATE handler, but that doesn't make a visual difference. Without the SetWindowLong call the borders of the NC area aren't painted at all.
The border doesn't get painted, but that didn't happen in the first place, my problem was that not only the buttons were painted, but a small area around the buttons too, and there is a line drawn that seperates the client and the non-client area.
If I don't make a handler to NCACTIVATE at all windows paints the NC area as soon as it looses focus, otherwise not.
Maybe I didn't make myself entirely clear, but I would like windows to paint nothing at all outside of the client area, as windows refuses to draw the button without background.
Thanks in advance
|
|
|
|
|
1- _beginthreadex returns a HANDLE to the thread and the Thread ID in its last parameter. Am I right?
2- Do I have to keep the value returned by _beginthreadex in order to call CloseHandle on it, or can I safely ignore it without ending with resource leaks?
Tx
Michel
If I am wrong or said something stupid, I apologize in advance 
|
|
|
|
|
1. Yes.
2. Yes, No.
I vote pro drink ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Ok.. i have 2 grids in this project.. i upgraded to .NET, added a new grid to a new dialog and when i compile and run the program the 2 grids from before .NET show fine.. but the new one i added doesn't show up at all in the dialog.. i checked all of the properties of both and set them the same, but the one from .NET just doesn't want to show up.. it has visible = true..
it gives these lines in the output window when the dialog pops up:
'SCTax.exe': Loaded 'C:\WINNT\system32\clbcatq.dll', Cannot find or open a required DBG file.
'SCTax.exe': Loaded 'C:\WINNT\system32\Msflxgrd.ocx', Cannot find or open a required DBG file.
however it doesn't say anything like this whenever the older dialogs popup.. and i know that the Msflxgrd.ocx exists, because when i exit the program the output window says:
'SCTax.exe': Unloaded 'C:\WINNT\system32\Msflxgrd.ocx'
.. any suggestions anyone? this grid seems to be quite a pain to get to work in .NET.. im assuming its some sort of code that it left out when i added the control.
thanks for any suggestions
-dz
|
|
|
|
|
[you can call me naive, but] I've decided to try and build - from scratch - my own set of GDI controls. i.e., derive CWnd and do all the events and painting stuff by myself.
the main motivations for this is [a] I'd like to create specially shaped transparent controls and [b] I simply HATE those ones that MS gives.
when I tried to integrate the transparent functionality into my controls, I ran into a problem: the control should use the parent's DC to paint itself transparently. so I actually have to call my control's Draw() function (from the parent's OnDraw() function), passing it the parent's current paint DC. it seems lame to me, but sadly I didn't find any other way to do it.
I did that after I tried to intercept WM_PAINT, but it kept on calling my OnPaint() handler and it didn't give enough time for the other controls to paint their own data.....
so I investigated how MFC draws its own simple controls (CButton), and found that actually the parent's DC is being used for drawing the child control. but where? and who does the actual drawing? where in the background is that control being drawn on the screen, and re-WM_PAINT-ed everytime it should be redrawn?
I want to fully understand the simple control's display behaviour and to integrate it into my own set of controls.
any explanations, guidelines, pointers, suggestions will be very appreciated.
|
|
|
|
|
alpha+ wrote:
so I investigated how MFC draws its own simple controls (CButton), and found that actually the parent's DC is being used for drawing the child control.
I find this statement incorrect. How did you get this?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
When you register your class for the child control, give it the class style CS_PARENTDC.
Then create an OnDraw OnPaint handler for your child control. The parent control will get the chance to paint its display first, then your child control will get its chance.
You shouldn't have to call the OnDraw handler directly, windows or MFC will take care of that for you.
|
|
|
|
|
One other thing that I forgot to mention.
In order to make a child control look transparent, you will need to handle the WM_ERASEBKGND message for you child control, and return FALSE. This will have the effect of your child control not clearing the window space below it with the default color for a window like white or whatever, and it will allow what appears on the parent control to show through for the child controls display surface.
Then when you paint the text or whatever for your child control, it will appear as though the control is transparent.
One other note, with this fix, it is no longer neccesary to use the parent windows DC. I told you in my previous post that in order to use the parent DC, set the CS_PARENTDC style for your class, this is no longer necessary.
|
|
|
|
|
You should use regions to handle transparency. They are very cool! Create an odd shaped region (CRgn) and select it (SetWindowRgn) into your device context. Windows will automatically paint only within the region. You can even have windows with holes!
See this article and this one too for instant inspiration.
/ravi
"There is always one more bug..."
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
I think that SetWindowRgn is a good way to go for irregular shaped windows and windows with holes, like you said, however, if you want the control to be transparent, but still be able to click on a that transparent portion and have your child control respond, you will need to handle the WM_ERASEBKGND message and not erase the background.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
