|
Sorry about the formatting, it was the first time I posted anything with code here.
The value is not always the same, it's whatever is last on the list. If the right list has the following strings:
"1"
"2"
"4"
"7"
"10"
"11"
Selecting "2" and clicking on the move left button will get the "11" and it will be moved to the left. If you then select the "2" again (or anything else on the list) and click on the move left button, the "10" will be selected and moved.
What gets selected is whatever is last on the list. The code for moving from the left box to the right is identical except for the control name and selecting the "2" would actually fetch the "2" from index 1 and move it.
The index fetched in both cases is correct. What isn't working is the code that gets the value for the index.
I'm completely baffled. The two are coded the same.
|
|
|
|
|
Why are you casting string values to floats in your code? You should use your debugger to step through the code and see exactly what values are being stored in your array (and why is it declared with two int fields?), and how they are matching the items in the lists.
|
|
|
|
|
SetItemData allows you to associate a 32 bit value with the index and GetitemData retrieves that data. When I do the AddString to put the strings in the list box, if successful I load a float value associated with the string with SetItemData. When retrieved it has to be cast back to float because GetItemData returns a DWORD.
In this particular dialog the data is stored as a float, but is always an integer. The program does this because the same data space can be used for float values too, but if you're in this dialog, the data will always be integers stored as floats.
|
|
|
|
|
You may debug your application and inspect all list items (index, string, value); optionally also using TRACE statements.
But you should also show the code used to add items to the right list box because the source may be there (I guess that it is empty upon program start).
When the list box has sorting enabled, the order of items shown on screen does not correspond to the indexes. So when adding an item, it should look like:
int ndx = m_lstRight.AddString(strItem);
m_lstRight.SetItemData(ndx, val);
|
|
|
|
|
The box isn't sorted, but that's how I assign data to the list box:
int idx;
idx = m_lstRight.AddString(szStr);
if(idx = LB_ERR)
{
m_lstRight.SetItemData(idx, (DWORD)val);
}
I looked at the data being assigned to the list box and everything was fine. I haven't figured out how to look at the data in a CListBox. I put a watch on it, but I didn't see where the data was stored when I inspected the control.
|
|
|
|
|
That will set idx to LB_ERR. I don't know what happens with the SetItemData call then but there are two options: It will fail or set the value of the last item in the list.
It should be:
if(idx != LB_ERR)
{
m_lstRight.SetItemData(idx, (DWORD)val);
}
When SetItemData fails when passing LB_ERR (which is most probable), you can remove the if condition.
[EDIT]
Just a tip for such conditions: Exchange the expressions.
If you would have used
if(LB_ERR = idx)
you would have got a compiler error and noticed your fault.
|
|
|
|
|
That's the problem! For some reason when setting the left box, the exclamation point was in there, but it was missing from the setting of the right box. That usually flags an warning on compile. I wonder why it wasn't.
It appears SetItemData is doing something though. The value returned with GetItemData is always the last value on the list. The list redraws after a move, so all the items were probably getting set to the last value for some reason I don't understand.
It works now.
I think I need glasses...
Thanks!
|
|
|
|
|
Fine to hear that the problem is solved.
If you use the tip from my edited previous post you will avoid such errors in the future. I'm using that since some years and it probably saved me a lot of time.
According to your description it seems that SetItemData is setting the value of the last item when passing LB_ERR (like with other list box function when passing -1).
|
|
|
|
|
wdolson wrote: usually flags an warning on compile.
It is a valid expression in C++, but newer versions of the compiler do, I think, give a warning about it.
|
|
|
|
|
What I'm looking for is the basic equivalent of the following functions
pair<Blob, Blob> GenerateKeyPair();
void Encrypt(Blob & data, Blob key);
void Decrypt(Blob & data, Blob otherkey);
Expectations: Free for commercial use, source code or static library, quality algorithm, quality code, no babbling about prime numbers and padding and Bob's love live in the documentation. Ideally doesn't pull in a massive project that takes an hour to configure and build.
Doesn't need to be blindingly fast, doesn't need to thwart the NSA or the credit card mafia.
I've looked at Crypto++ as most likely candidate, but it's still not exactly lazy dev friendly.
(I tried to post in quick answers, but it wouldn't let me. Maybe there's now half a dozen duplicate questions in you database, Chris!)
|
|
|
|
|
How to communicate between two different app using Send Message API?
Ex:
APP1 having textbox txtBox1
APP2 having textbox txtBox2
In txtbox1 whats ever we type, that needs to be displayed in textbox2.
How to achieve it using SendMessage() API.
Ex code in VC++ is appreciated.
|
|
|
|
|
|
Thanks for your help.
I am facing issue in extracting the message.
Code is as follows...
APP1:
int WM_MYMSG = RegisterWindowMessage (L"MYMESSAGE");
HWND hw = FindWindow(NULL, L"Demo");
LPCTSTR strMsg = L"ClientDemo1";
::SendMessage(hw, WM_MYMSG, NULL, (LPARAM(LPCTSTR)strMsg);
APP2:
LRESULT CDemoDlg::OnMyMsg(WPARAM w, LPARAM l) {
MSG* p = (MSG*)l;
LPCTSTR str = (LPCTSTR)p->message;
MessageBox(str);
return (LRESULT) 0;
}
Please let me know what changes is needed here by which it'll display "ClientDemo1" in msgbox.
|
|
|
|
|
The LPARAM in your sending application is a Unicode string, so why are you casting it to a MSG pointer in the receiving app?
|
|
|
|
|
I am just finding the way to print the message.
So you mean to say it is not needed and directly we can use lparam to print the message?
|
|
|
|
|
Anasuya2015 wrote: So you mean to say ...
No, I am saying that whatever type you use in the LPARAM field in the sending app, you must use the same type in the receiver.
|
|
|
|
|
Your casting is a bit unclear. It should probably be:
::SendMessage(hw, WM_MYMSG, NULL, (LPARAM) strMsg);
...
LPCTSTR str = (LPCTSTR) l;
MessageBox(str);
The process calling SendMessage() will likely be blocked by the second process since it will be waiting on the message box to be dismissed.
"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
|
|
|
|
|
You can use COM automation, Named Pipes, TCP/IP Sockets or whatsoever by implementing your own protocol for interprocess communtication. 
|
|
|
|
|
Here requirement is restrict to SendMessage() API.
Anyway thanks for your answer. Can you send any sample code for Named Pipes implementation?
|
|
|
|
|
|
Also you can reuse SendMessage() API function with its regular list of arguments by implementing your own that encapsulates for example named pipes client mechanism.
|
|
|
|
|
You can use WM_COPYDATA[^] message with SendMessage API
There is a linked example on MSDN topic as well
|
|
|
|
|
This is what we use and it works nicely
I'd rather be phishing!
|
|
|
|
|
Hi
I am wondering if anyone can point me in the right direction
I am getting strange results
When I try to move a DWORD to a char[4] I am running in 64 bit mode and it my understanding that both are 32 bits long
The DWORD has 4 bytes of a ebcdic character string
I want to move the DWORD to char 4 so that I can access every character and convert it to ascii when I try to move 1 of the chars to a unsigned int e.g. Unsigned int c = str[1] the result in c is a negative number maybe the high order bit in str[1] byte is on but by moving it to a unsigned int shouldn't that do away with making the result negative for example moving a D0 results in FFF2
Any help appreciated
Thanks
|
|
|
|
|
I think the problem comes from the way bytes are ordered in memory.
When you treat a 4-byte block as a DWORD, the bytes are not in order from MSB to LSB. It depends upon your hardware.
You can verify this in the debugger. Place a breakpoint anywhere you are using the DWORD variable, and then when it breaks, switch to Disassembly view. (Make sure "Show code bytes" is on.) You'll see the way the bytes are ordered, and it's not what you expect!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
