|
I have a constants.h file that I would like to use to store constants and such.
When I include the file in a class in my project I keep getting Link Error:2005: "already defined in" errors when I try to declare a string constant in the constant.h file.
How do I create global string constants that I can use througout my app?
// constants.h: defines constants to be used througout application.
//
//////////////////////////////////////////////////////////////////////
#if !defined(APP_CONSTANTS_0209051212)
#define APP_CONSTANTS_0209051212
//no problems here
const APP_PATH_STRING_LENGTH = 255;
//link errors when using these
char* app_data_path = "data\\";
char* app_charts_path = "c:\\CHARTS\\";
#endif // !defined(APP_CONSTANTS_0209051212)
Kevin Shaffer
kshaff03@msn.com
|
|
|
|
|
I made the strings static, which appears to have solved my problem. Is this the best way to handled such a problem?
char* app_data_path = "data\\";
char* app_charts_path = "c:\\CHARTS\\";
to:
static char* app_data_path = "data\\";
static char* app_charts_path = "c:\\CHARTS\\";
Kevin Shaffer
kshaff03@msn.com
|
|
|
|
|
kshaff03 wrote:
Is this the best way to handled such a problem?
nope.
the best way is like this:
foo.cpp:
#include "foo.h"
const char* app_data_path = "data\\";
const char* app_charts_path = "c:\\CHARTS\\";
foo.h
extern const char* app_data_path;
extern const char* app_charts_path;
making them static just means that every .CPP will get its own private copy of the strings.
Image Toolkits | Image Processing | Cleek
|
|
|
|
|
Thanks Chris,
As usual, your the best.
-Kevin
Kevin Shaffer
kshaff03@msn.com
|
|
|
|
|
I am using Microsoft Visual C++ 6.0 and i need to execute a program (Ctrl+F5) passing it same arguments (as command line arguments), where can i put the arguments ?
Thanks.
|
|
|
|
|
You can pass any command line arguments to your program in the projects settings, under the Debug tab, in the Program arguments edit box.
I Dream of Absolute Zero
|
|
|
|
|
It will use the same arguments that you setup in the project settings.
Project->Settings->Debug
Program arguments field
NOTE: This is the same path for both release and debug builds
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
|
How to program proxy chains software?
Love is the law, love under will.
|
|
|
|
|
can any1 help me?
Love is the law, love under will.
|
|
|
|
|
I'm a "seasoned" SQL, SQR, COBOL, Easytrieve programmer teaching myself Win32 programming.
I'm creating a Wheel of Fortune type game using a dialog box. I've got the alphabet across the top of the screen, I can accept a letter choice and blank it out if it's not in the puzzle.
But here is the problem...can I use a dialog box to put random EDITTEXT boxes on a page that represent the puzzle?
For Example: PUZZLE 1 ___ ___ ___
___ ___ ___
PUZZLE 2 ___ ___ ___ ___ ___
Don't know how my resource script file can handle a random number of EDITTEXT boxes? I'm just trying this to get a feel for message based programming. Is a dialog box the wrong approach?
Thanks,
dC
|
|
|
|
|
Dialog box is probably okay for a learning program such as this.
You can CreatWindow on the fly and generate the edit boxes.
There is typically (or used to be) limit of 255 controls in one window.
I don't suppose you need that many, though, for your game.
You can create them in the desired lcoation, or use MoveWindow to position them.
If you make a dialog reosurce template, you could use ShowWindow and EnableWindow to show/hide enable/disable the ones your puzzle does not need at the time.
|
|
|
|
|
Ah, the lightbulb comes on!
I could just set up a whole slew of EDITTEXT boxes (or just limit the puzzle answers to say 20 characters) in my .rc file. Once I pull the randow puzzle I can just "show" the boxes I need with something like "SetWindowText(hwndLtr1, "______");"
Thanks,
dc
|
|
|
|
|
Yes, and to make it look more like the game, you can HIDE and DISABLE the edit boxes that don't match the current puzzle.
|
|
|
|
|
Blake Miller wrote:
There is typically (or used to be) limit of 255 controls in one window.
Ummm nope, there never was. Visual C++'s dialog editor has a limit on how many controls it supports on a dialog (255), but the limit as to the number of controls Windows supports is limited only by physical memory and the number of available window handler.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I beg to differ.
A BYTE was used, previously, to store the control's identifier, thus limiting the number of child windows to 255 in the resource template. Since most people used dialog templates and not in-memory dynamic resource tempaltes, they were 'essentially' limited to 25 controls on a single dialog.
Of course, if you are just building windows on the fly, you are limited only by memory or GDI resources, or some other commodity you will eventually deplete.
Another thing is, even though the current windows systems are typically entirely 32 bit environments, there are still many 'window identifiers' passed around as the upper or lower 16-bits of various window messages, so you are, in some cases, limited to 65535 windows, depending upon your circumstances.
As far as 'child controls' the window control child identifier is a 16 bit number, so even if you made more than 65535 child control windows, you would only be able to distinguich 65535 of them from each other. And you would also run into the messaging LOWOR/HIWORD problem. Just see the wParam of the WM_COMMAND message, and I quote MSDN:
The high-order word specifies the notification code if the message is from a control. If the message is from an accelerator, this value is 1. If the message is from a menu, this value is zero.
The low-order word specifies the identifier of the menu item, control, or accelerator.
|
|
|
|
|
Blake Miller wrote:
I beg to differ.
How is that different from what I said?
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
"...the limit as to the number of controls Windows supports is limited only by physical memory and the number of available window handler."
The number of window handles is not the same as the number of available control identifiers. The limit of HWND is not the same as the numerical limit of UINT control identifiers. That is the difference I perceived between what I had said and what you had said.
AND since the original poster was asking about dialogs and controls on dialogs, it made sense to be very specific as to what limitations exist and what issues he might run into.
|
|
|
|
|
Blake Miller wrote:
The limit of HWND is not the same as the numerical limit of UINT control identifiers.
While we're being pedantic, I'll mention that it is for Win95, 98 and ME - where only 65535 unique HWNDs are available (even though an HWND is 32 bits). Besides, control identifiers only have to be unique within a single parent window. Two different parent windows can have controls with the same identifiers. So if the dialog includes child windows that contain other controls, the limit on identifiers is not really relevant.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Blake Miller wrote:
There is typically (or used to be) limit of 255 controls in one window.
That limit was imposed by the resource editor, not dynamically-created controls.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
I have following code in a cpp file:
//test.cpp
int __cdecl calc1 (int a, int b, int c) {
return (a+b-c);
}
int __cdecl calc2 (int a, int b) {
return (a+b);
}
void main() {
int r = calc1(10,20,5);
r = calc2(10,20);
}
I have compiled this with 'cl' command. Then, with "dumpbin /disasm test.obj command I created following file: (I have removed the headers here)
?calc1@@YAHHHH@Z (int __cdecl calc1(int,int,int)):
00000000: 55 push ebp
00000001: 8B EC mov ebp,esp
00000003: 8B 45 08 mov eax,dword ptr [ebp+8]
00000006: 03 45 0C add eax,dword ptr [ebp+0Ch]
00000009: 2B 45 10 sub eax,dword ptr [ebp+10h]
0000000C: 5D pop ebp
0000000D: C3 ret
?calc2@@YAHHH@Z (int __cdecl calc2(int,int)):
0000000E: 55 push ebp
0000000F: 8B EC mov ebp,esp
00000011: 8B 45 08 mov eax,dword ptr [ebp+8]
00000014: 03 45 0C add eax,dword ptr [ebp+0Ch]
00000017: 5D pop ebp
00000018: C3 ret
_main:
00000019: 55 push ebp
0000001A: 8B EC mov ebp,esp
0000001C: 51 push ecx
0000001D: 6A 05 push 5
0000001F: 6A 14 push 14h
00000021: 6A 0A push 0Ah
00000023: E8 00 00 00 00 call 00000028
00000028: 83 C4 0C add esp,0Ch
0000002B: 89 45 FC mov dword ptr [ebp-4],eax
0000002E: 6A 14 push 14h
00000030: 6A 0A push 0Ah
00000032: E8 00 00 00 00 call 00000037
00000037: 83 C4 08 add esp,8
0000003A: 89 45 FC mov dword ptr [ebp-4],eax
0000003D: 8B E5 mov esp,ebp
0000003F: 5D pop ebp
00000040: C3 ret
On line 00000023 in the main function it calls calc1 function,
But no where address of calc1 (00000000) is mentioned.
The same case happens when call to calc1 (0000000E) is made.
So, how the control will be transferred to respective functions?
Could anyone help me in understanding the working of call instruction and explain the calling of proper function in the above case?
|
|
|
|
|
The first function called
r = calc1(10,20,5); becomes
0000001D: 6A 05 push 5 - Parameter 5
0000001F: 6A 14 push 14h - Parameter 20
00000021: 6A 0A push 0Ah - Parameter 10
00000023: E8 00 00 00 00 call 00000028
00000028: 83 C4 0C add esp,0Ch - Alter the next execution
0000002B: 89 45 FC mov dword ptr [ebp-4],eax - Get the result
The second function called
r = calc2(10,20); becomes
0000002E: 6A 14 push 14h - Parameter 20
00000030: 6A 0A push 0Ah - Parameter 10
00000032: E8 00 00 00 00 call 00000037
00000037: 83 C4 08 add esp,8 - Alter the next execution
0000003A: 89 45 FC mov dword ptr [ebp-4],eax - Get the result
When the function is called epb holds the return address. You will notice that this needs to be preserved pushed and popped at start and end of function respectively.
Ant.
I'm hard, yet soft. I'm coloured, yet clear. I'm fruity and sweet. I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
Rajas P wrote:
Could anyone help me in understanding the working of call instruction and explain the calling of proper function in the above case?
The problem is that you've dumped the object file rather than the executable. When the compiler compiles the file, it doesn't know where in memory the function is going to be located, so it generates a call instruction with a dummy address in it (in this case, 0x0000000), and generates a separate FIXUP record in the COFF object file that tells the linker to fill in the correct address when it links the object files and determines where in memory everything is going to be located. This is why the two calls are actually referencing the same address in the disassembly above - neither of them have had the actual code location inserted by the linker yet.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I've to develop a SNTP server. I know the SNTP packet structure, and the SNTP port.
Is the SNTP server a simple server socket that replies to clients with an updated SNTP packet or there is something
more ???
Thanks a lot.
|
|
|
|
|
|