C / C++ / MFC

3-Apr-11 22:02

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 ?

CPallini3-Apr-11 22:41

3-Apr-11 22:41

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?
Smile | :)

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]

_Flaviu3-Apr-11 23:37

3-Apr-11 23:37

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 ?

CPallini3-Apr-11 23:53

3-Apr-11 23:53

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.
Smile | :)

_Flaviu4-Apr-11 0:31

4-Apr-11 0:31

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 ... Frown | :(

CPallini4-Apr-11 0:28

4-Apr-11 0:28

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):

C++

TCHAR a[2];
int nResult = ::GetLocaleInfo(LOCALE_USER_DEFAULT,LOCALE_SDECIMAL,a,2);
SHORT vkCode =  VkKeyScan(a[0]);

_Flaviu4-Apr-11 0:49

4-Apr-11 0:49

Didn't working , because

SHORT nDecimal = VkKeyScan(m_chDecimalSymbol);

return 190 , which is not 46 (.) ....

CPallini4-Apr-11 1:51

4-Apr-11 1:51

It's correct: 190 is VK_OEM_PERIOD, that is the scan code of (the lef hand) key for the '.'.

Stefan_Lang4-Apr-11 0:28

4-Apr-11 0:28

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... Wink | ;)

_Flaviu4-Apr-11 0:33

4-Apr-11 0:33

Ok , thank you .

_Flaviu4-Apr-11 1:02

4-Apr-11 1:02

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 !

Stefan_Lang4-Apr-11 22:34

4-Apr-11 22:34

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.

David Crow4-Apr-11 10:52

David Crow

4-Apr-11 10:52

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

Stefan_Lang4-Apr-11 22:27

4-Apr-11 22:27

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. Mad | :mad:

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.

problem with print valu

a1_shay3-Apr-11 19:58

a1_shay

3-Apr-11 19:58

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);
//destroy(pol1);
}

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);
}

Niklas L3-Apr-11 21:22

Niklas L

3-Apr-11 21:22

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.

home

a1_shay3-Apr-11 21:39

a1_shay

3-Apr-11 21:39

but after i free the POL1 i did
pol1=nod
and then ++(pol1->size)
so size is supposed to be 1

Niklas L3-Apr-11 22:18

Niklas L

3-Apr-11 22:18

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));
    // Here, 'pol1' will be have been updated
    printf("%d\n", pol1->size);
    //destroy(pol1);
}

home

Stefan_Lang4-Apr-11 4:43

4-Apr-11 4:43

The problem is that

int push(Node *poll, int hez, int mek)

passes the pointer poll by value, not by reference. The assignment poll=node; is valid within push(), but the change will not be passed to the caller. As a result, after calling push() the pointer poll in main will still point to the memory location of your first node, but this node was already freed. The newly created node will be lost, as you failed to pass the pointer back to main. Your print statement accesses poll->size which is now undefined and can have any arbitrary value.