A couple of seconds ago, I just eliminated the "atlsd.lib" library from the Additional Dependencies ... though I have a "ImageList_Create()" call that, according to MSDN, requires the library "ImgCtl.lib", this library doesn't seem to be anywhere. So I just added "comctl32.lib", and everything linked correctly .
Please don't ask me why, since I did the same thing at the beginning and it didn't work ...
I just ask myself if I can really trust this environment.....
Thank you anyway for the support.
The environment is fine, but you seem to be using some strange libraries. For example, look at the documentation for ImageList_Create()[^], there is no mention of ImgCtl.lib; what documentation are you working from?
One of these days I'm going to think of a really clever signature.
I am using MSDN for VS 2008 ... actually when looking at ImageList_create(), I didn't realize I was reading the Windows CE 5.0 documentation, which includes "ImgClt.lib". Just trying I realized comctl32.lib is enough. Anyway the real problem seems to have been my inclusion of atlsd.lib, which I did when I realized the _recalloc() couldn't be linked. I don't know what changed but now it seems to be ok ... anyway I keep having serious doubts about the reliability of the environment , since more than once , building twice the same application without making any change between builds, I got different and contrasting results ...
There are probably millions of people around the world using Visual Studio to build their applications. If there was such a fundamental flaw in it then I think it would have been brought to Microsoft's attention by now. I have used the express versions (2005, 2008 and 2010) and never come across anything even vaguely resembling your problem. But if you are trying to include CE libraries into a standard desktop application it's little wonder that things are looking strange.
One of these days I'm going to think of a really clever signature.
Well I agree with you .... even though , there are tons of people who see such strange things and never report to Microsoft ... and most of them don't even dare thinking there's a problem ... .... Anyway , I don't think what I saw, that is , those two differents results with two builds of the same version, can be caused by any programmer's error....
I need your suggestion for my following questions.
Recently i have buillt one standalone desktop software application and my question is ,
1. Application should be installed only one pc.
2. Once installed single PC it wont work/install otherPC/same PC next time.
3. We cannot used database for that application, also internet connection.
Not a C++ question, and you haven't provided enough information to answer the question without making a lot of assumptions.
So, assuming the platform is Windows, and that the PC is not connected to the internet:
1. Make a pre-install application that reports a unique ID for the PC. If you don't fancy rolling your own algorithm (not recommended), consider using the value found in the Registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId which is probably unique and tied to an installation of Windows (see this StackOverflow discussion).
2. Once the user has run this application and reported the unique number, use it, with a secret key and a suitable hashing algorithm, to generate a unique hash tied to this ID. Deliver this hash to the user (in a letter, or email to other PC, or in a text message, or however you like).
3. In the installer, get the unique ID (by reading the Registry above), apply the hashing algorithm, ask the user for his or her hash, and compare the two. If they correspond, this is the correct PC, if not, abort the installation.
4. After installation is complete, Windows Installer will make a that this application has been installed. You can check this at the start of the installer to make sure it's not re-installed.
Basically, if you want to limit an application to be installed on only one PC, you need some way of identifying this single PC. If internet access isn't available, it can't be done during installation, so will need to be done in a two-step process.
Orjan Westin's suggestion of a unique key is probably the way to go, but you could also consider a hardware "dongle", e.g HASP, KeyLok, SecuTech etc.
The key can be shipped to the customer with the product media, or delivered separately when they request a license, and will ensure only one copy of the software is running per key supplied. Some dongle systems allow for upgrading, enabling additional features, and time-limited trial versions as well.
Days spent at sea are not deducted from one's alloted span - Phoenician proverb
I am have C++ files (.h, .cpp) that include functions to read a specify file type (.dgn). And I want to use these functions in C# for the same purpose . I am intending use "__declspec(dllexport)" to use C++ functions.
But, I don't know what type in C# is similar to "typedef void *" in C++.
Please see belows is C++ codes
/** Opaque handle representing DGN file, used with DGN API. */
typedef void *DGNHandle;
DGNHandle CPL_DLL DGNOpen( constchar *, int );
void CPL_DLL DGNSetOptions( DGNHandle, int );
int CPL_DLL DGNTestOpen( GByte *, int );
const DGNElementInfo CPL_DLL *DGNGetElementIndex( DGNHandle, int * );
I have one dialog box (parent). I have a button on this dialog box. On clicking this button I'll invoke second dialog (child) (modal dialog). Now I want to keep track of an instance in child dialog that it has been invoked second time. I mean to say when I click on the button, this dialog will be Poped Up. Now in any of the functions defined in the child dialog, I want to know that this dialog has been invoked second time and also I want to save the state of any variable defined in the child dialog. for example if I have set a variable as 1 in child dialog, Now when I invoked this dialog second time, I should get the variable's value as 1.
1. Store the information in static member variables in the child dialog.
2. Store the information in member variables of the parent dialog, pass it to the child dialog before calling DoModal() and retrieve the information when DoModal() returns.
3. Store the information in the registry below your application key. This is usefull when settings should be re-used when starting your app the next time. Information that is only used during the app execution time (e.g. the counter) should not be stored in the registry. But you may use a combination of registry with option 1. or 2.
Agree with some of other post, there is one more solutions, create a data class in your parent dialog class and pass as reference everytime the child dialog is invoked and all data modification should be done with the reference object, this way you will not have declare anything static and data would be at one place only!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture