|
I elaborate just a bit the good Superman's answer.
The CheckBox 'check' is a GUI event and should be handled by the GUI code (as Superman already suggested, you typically handle the BN_CLICKED notification code of the WM_COMMAND message in the parent window of the CheckBox control).
The best way to 'notify something' to a DLL is calling a DLL's function. So:
- Define a
DLL function, e.g. OnMyCheck(). - In the parent window of the
CheckBox control handle the WM_COMMAND message: on BN_CLICKED notification coming from the CheckBox control call in turn the DLL's function OnMyCheck.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
both good answers, my 5 to both.
|
|
|
|
|
thanks so much
|
|
|
|
|
I am using cFileDialog to save a file on disk, I used OFN_OVERWRITEPROMPT flag to prompt for overwriting a file. Is there anytihing can be done if drive is full?
|
|
|
|
|
You mean you're using cFileDialog to get the filename or to save the file? (or both?)
Er, um - why wouldn't you just catch the error-code generated by calls to CreateFile or WriteFile - surely there will be a hint of the lack of diskspace there??
Alternately, if you wish to prevent the selection(creation) of a file on a disk that you already know to be full - wouldn't you just check the returned path from an OpenFileDialog - ensuring that it doesn't exist on the full disk. If the prohibited disk is chosen, you could just re-show the dialog along with a message advising the user to choose a location on another drive.
|
|
|
|
|
You might check for sufficient disk space (using GetDiskFreeSpaceEx) before asking for a specific file path, but then you would be assuming the partition or disk to be known beforehand. Or you might check all partitions to make sure each of them has sufficient free space, but then every small or full partition would distract the user's attention. So you have to choose an approach that fits your most likely situation.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
The file dialog only responsibility is too get the name of a file (and path), it does not know the size of the data to be written to the disk.
You could add a hook to warn about low disk space when the user change the path in the file dialog.
It's your job to handle errors from the various APIs and SDK calls that will create the file.
Watched code never compiles.
|
|
|
|
|
If I get locale decimal point in follow way :
TCHAR m_chDecimalSymbol;
m_chDecimalSymbol = _T('.');
int nResult = ::GetLocaleInfo(LOCALE_USER_DEFAULT,LOCALE_SDECIMAL,sTemp.GetBufferSetLength(2),2);
sTemp.ReleaseBuffer();
if(nResult)m_chDecimalSymbol = sTemp[0];
and now I want to know which is keycode of m_chDecimalSymbol :
UINT nDecimal = m_chDecimalSymbol - '0'; \\ <-- is wrong
can you help me , please ?
|
|
|
|
|
Flaviu 2 wrote: UINT nDecimal = m_chDecimalSymbol - '0'; \\ <-- is wrong
Why are you using such (wrong) technique? Shouldn't be VK_DECIMAL the (virtual) key code you are looking for?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Here is remarks of VK_DECIMAL :
A virtual key code for the numeric keypad DECIMAL POINT (.) key.
but what is happen if the user hit point (.) not from numeric keyboard ? Or when decimal separator is comma (,), not point ?
|
|
|
|
|
Flaviu 2 wrote: but what is happen if the user hit point (.) not from numeric keyboard ?
You are right on this, it wouldn't be detected.
Flaviu 2 wrote: Or when decimal separator is comma (,), not point ?
You are wrong here, the key on numerical keypad alway corrensponds to the decimal separator.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I learn something here , that the point key from numerical keyboard corespond to decimal separator , whatever it would be , thank you for that ... but still , I didn't know how to get keyboard code of global decimal separator ... 
|
|
|
|
|
Flaviu 2 wrote: but what is happen if the user hit point (.) not from numeric keyboard ?
You may find the scan code for such a key this way (at least it works on my system):
TCHAR a[2];
int nResult = ::GetLocaleInfo(LOCALE_USER_DEFAULT,LOCALE_SDECIMAL,a,2);
SHORT vkCode = VkKeyScan(a[0]);
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Didn't working , because
SHORT nDecimal = VkKeyScan(m_chDecimalSymbol);
return 190 , which is not 46 (.) ....
|
|
|
|
|
It's correct: 190 is VK_OEM_PERIOD, that is the scan code of (the lef hand) key for the '.'.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Flaviu 2 wrote:
sTemp.ReleaseBuffer();
if(nResult)m_chDecimalSymbol = sTemp[0];
As an aside, you should swap these two lines. Doesn't make sense to read sTemp after releasing its buffer... 
|
|
|
|
|
|
My foulish !
UINT nDecimal = (UINT)m_chDecimalSymbol;
Thank you all , from your patient , plus , I learn something here , it's alway a pleasure to talk with you !
|
|
|
|
|
Regarding my statement about ReleaseBuffer(), it turned out I was wrong. In your example it probably doesn't make a difference, but, generally speaking, it was correct to call it when you did.
Just wanted to let you know, as you may not aware of new posts that are not in response to you, personally. See David Crow's response to my previous posting in this thread for more info.
|
|
|
|
|
Stefan63 wrote: Doesn't make sense to read sTemp after releasing its buffer...
Sure it does. As a matter of fact, you shouldn't do anything with sTemp until you have released it's internal buffer.
"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
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Thank you for reminding me why I hate working with MSDN classes. The term 'ReleaseBuffer' appears to be pretty clear on what it does, but like so many times, MS has its very own and unique understanding. 
My error was to only check on GetBufferSetLength(): GetBufferSetLength at MSDN.
Unfortunately the explanation of true meaning of the effect of ReleaseBuffer after GetBufferSetLength() is ambiguous, although, based on the function name I didn't realize that. In fact, when I checked ReleaseBuffer just now, I found that it also isn't clear - that is, it isn't until you look at the code example. Or, more to the point, the comments added in there. Without that example I might in fact still question your assertion.
I'm still unsure whether it is required to call ReleaseBuffer() before accessing the CString variable; according to the documentation all it does is resize the buffer to the required size and, optionally, insert a terminating 0 character. The latter isn't required since GetLocaleInfo() already does it. The former isn't needed either, as the buffer was allocated with the correct size.
If there is any other hidden functionality of ReleaseBuffer(), I am not aware of it.
|
|
|
|
|
the code is print one time correct and one time junk.i didnt anderstand why he print junk
the program in c
main file
#include<stdio.h>
#include<malloc.h>
#include"tal.h"
void main()
{
Node *pol1=create();
printf("%d\n",push(pol1,2,3));
printf("%d\n",pol1->size);
}
h file
typedefstruct node
{
int mekadem;
int hezka;
int size;
struct node *next;
} Node;
Node *create();
int push(Node *pol1,int a,int b);
ex.c file
#include<stdio.h>
#include<malloc.h>
#include<stdlib.h>
#include"tal.h"
Node *create()
{
Node *q = (Node*)malloc(sizeof(Node));
q->hezka=0;
q->mekadem=0;
q->next=NULL;
q->size=0;
return q;
}
int push(Node *pol1,int hez,int mek)
{
Node *temp=pol1;
Node *followtemp=pol1;
Node *node=(Node*)malloc(sizeof(Node));
node->hezka=hez;
node->mekadem=mek;
node->size=0;
node->next=NULL;
if(pol1->size==0)
{
free(pol1);
pol1=node;
}
return ++(pol1->size);
}
|
|
|
|
|
In create() you are creating a new node, setting size to zero. In push() you check if size is zero, and then free the node. Your pointer poll will no longer be valid.
|
|
|
|
|
but after i free the POL1 i did
pol1=nod
and then ++(pol1->size)
so size is supposed to be 1
|
|
|
|
|
Member 7809860 wrote: but after i free the POL1 i did
pol1=nod
Yes, but that only changes the local reference to your node.
If you want the callers value to be updated you will need something like:
int push(Node **pol1,int hez,int mek)
{
Node *temp = *pol1;
Node *followtemp = *pol1;
Node *node = (Node*)malloc(sizeof(Node));
node->hezka = hez;
node->mekadem = mek;
node->size = 0;
node->next = NULL;
if ((*pol1)->size == 0)
{
free(*pol1);
*pol1 = node;
}
return ++(*pol1->size);
}
and call it like
void main()
{
Node *pol1 = create();
printf("%d\n", push(&pol1, 2, 3));
printf("%d\n", pol1->size);
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
