|
Check in Resource.h file to see if those two radio buttons has consecutive values ... might be a problem if they are not.
|
|
|
|
|
_Flaviu wrote:
Check in Resource.h file to see if those two radio buttons has consecutive values ... might be a problem if they are not. |
Yes, that it was, in the resource.h the values of the radio butons were reversed, first it was Radio2 then Radio1. I putted their correspondent values in increasing order and problem was solved.
Many thank Flaviu
|
|
|
|
|
You are welcome  I am glad to help !
|
|
|
|
|
I just created a quick test with your code and it works fine. There must be something else happening that we cannot see. As suggested by Flaviu above, please check the defined values for the dialog buttons.
|
|
|
|
|
In addition what was said before, I suggest you add a default case for the inner switch in WM_COMMAND. Then set a breakpoint on that default. Maybe you're missing a case in that switch statement?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
I got a strange message from my compiler. Same code, same (at nearly) settings for Debug and Release versions. But what is more important, same files and same code! But when I try to create Release version, I get this:
Error CVT1100 duplicate resource. type:MANIFEST, name:1, language:0x0409 WTL3 C:\Users\Andrew\Documents\Visual Studio 2015\Projects\WarperPro\CVTRES 1
But Debug version can be created. Any ideas? I checked the project's settings and found nothing suspicious.
|
|
|
|
|
|
Check your Linker and Manifest settings in the project properties. It may be that you have a manifest reference in your resource file that should not be there, or is not being added correctly.
|
|
|
|
|
Thank you, your tip was useful. I checked all places in the project's settings where I met the word "manifest" and found one, where settings for Debug and Release were different. Release wanted to generate manifest file, but Debug did not. I excluded manifest generation for the Release version and finally got it.
|
|
|
|
|
Has happened to me more than once.
|
|
|
|
|
Look, guys, I have a code that worked properly under Windows XP 32 bit.
hHookMsg = SetWindowsHookEx(WH_JOURNALPLAYBACK, hkprc, hInst, 0). But under Windows 7 64 bit this call failed and I got System Error Message "Acces denied"
I tried this:
hHookMsg = SetWindowsHookEx(WH_JOURNALPLAYBACK, hkprc, hInst, GetCurrentThreadId())
and this
hHookMsg = SetWindowsHookEx(WH_JOURNALPLAYBACK, hkprc, (HINSTANCE)NULL, GetCurrentThreadId())
and got "This hook can be set only globally".
Any ideas how to resolve the situation?
|
|
|
|
|
They have put security around that sort of thing and you probably have to be running as administrator and it's likely going to throw a UAC to user to confirm it is okay. Goto MSDN and look at the documentation.
In vino veritas
|
|
|
|
|
Sure. I do not need this option- it was intended to demonstrate how my prog works to another users. And they do no not like (and for a reason) when some soft wants administrative privileges.
|
|
|
|
|
Member 14105155 wrote: And they do no not like (and for a reason) when some soft wants administrative privileges.
Well they are going to have to get used to it. Windows 10 (7 is out of support in a few days) uses this extensively in order to protect the users' systems from malicious software.
|
|
|
|
|
Well, this is the reason to write soft that works without such privileges.
|
|
|
|
|
You do not have a choice. The operating system sets the rules, and your software must work within those rules.
|
|
|
|
|
I do have. A program can ask a user if he let it run with privileges, but users dislike such soft. Therefore, the choice exists, but it is very poor one.
|
|
|
|
|
Member 14105155 wrote: Therefore, the choice exists, but it is very poor one.
On the contrary it is a very good one, as it allows the user to control which programs are allowed to make significant changes to their system.
|
|
|
|
|
I use this code:
Quote: BOOL C1095C::IsFileReady(CString path)
{
HANDLE hFile = CreateFile(path.GetBuffer(), GENERIC_READ, FILE_SHARE_WRITE | FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
return FALSE;
}
else
{
CloseHandle(hFile);
return TRUE;
}
}
while (!IsFileReady(output.GetBuffer()))
{
Sleep(1);
}
which waits for a file to be created and then once it is, it
proceeds to the next job. The problem is, this code doesnt seem to
work every time. Im nervous now in using it. I need to wait for a
file to be full created and sometimes it may take 5+ minutes. Once its
created, then I want to move onto the next step. How can I adjust this
code to make it work every time? Please any response any one can give me
will be great appreciated.
|
|
|
|
|
|
Is that Linux sleep() or Windows Sleep()? Or, more to the point, are you sleeping for 1 second, or 1 millisecond? If the latter, maybe you should try to increase the time to around 100ms: The Windows file system is not very fast, and might be hamstrung by constantly trying to open nonexistant files.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
It's clearly windows no such thing as CreateFile in linux and he already stated it can take 5min to open the file (I assume of a network drive) so 100ms is not going to change anything 
In vino veritas
|
|
|
|
|
In addition to Leon's suggestion, there's also FindFirstChangeNotification().
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
If you are waiting for the file to be fully created (i.e. completely written), then this code won't work. At best, it will wait until the file is created (i.e. when the other task opens it for writing).
The problem may be broken into two steps:
- Wait until the file is created (i.e. it appears in the directory)
- Wait until the file is closed (i.e. the writing is completed)
Others have given you good ideas about how to wait for the file to be created. In order to wait for the file to be completely written, the best way would be for the other application to create another file AFTER it is done with the data file. For example:
- Your application waits for the creation of DATA.DAT
- Other application creates file DATA.DAT (your application detects the creation)
- Other application writes into DATA.DATA (your application waits for the creation of FINISHED.DAT)
- Other application closes DATA.DAT
- Other application creates FINISHED.DAT (your application detects FINISHED.DAT, and knows that DATA.DAT is ready)
There are some other points to handle (e.g. what happens if DATA.DAT is created before your application starts waiting for it?), but this is the basic idea.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
IF you know that this will be on a local drive, an alternative is to create the file in a different directory and then move it to the target directory.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
