|
Why not simply use something like this:
---------------------------------------
// Console.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <iostream>
#include <string>
#include <sstream>
using namespace std;
void main()
{
string message = ":user.client computer1 sysinfo :sync1 smtp.startup";
istringstream iss(message);
string pt1, pt2, pt3, pt4, pt5;
iss >> pt1 >> pt2 >> pt3 >> pt4 >> pt5;
cout << "pt1 = " << pt1 << endl;
cout << "pt2 = " << pt2 << endl;
cout << "pt3 = " << pt3 << endl;
cout << "pt4 = " << pt4 << endl;
cout << "pt5 = " << pt5 << endl;
}
Steve
|
|
|
|
|
Did you solve your problem yet?
|
|
|
|
|
Yes thank you. Stephen Hewitt's suggestion worked out fine.
|
|
|
|
|
|
I have now downloaded two sets of the ACE TAO Corba (two different sites) for use initally with Visual Studio 2005. You seem to have to download all the source and build it. The first version built OK but something was missing; the IDL compiler did not general the required files. Is seemed that an ACEd.dll wa missing!
Start again, this time the ACE part built but about 57 projects of the TAO failed.
Can I ask where can you download a Corba environment and get it working with VS 2005, without all this hassle. After all I am only trying to 'Get Started' with Corba, not have a melt down before I try and write my first program.
PS I just opted for ACE TAO, are they a better option with some GYS notes?
Many thanks,
Andy.
|
|
|
|
|
Hi all,
I started using MAPs and STL not long ago and I still have some doubt.
I have to use the iData member of the class depicted below.
My Question is when I add new 'CStreetHouseNumber' values to iData,
where these value are stored? In the stack or in the heap?
iData is pointing a map into a heap, that is pointing another
map into the heap that is pointing a vector in the heap CONTAINING
values, but where these last values are
Thanks to everybody
Manu
class CAddressCollection
{
public:
CAddressCollection();
private:
class CStreetHouseNumber
{
public:
CStreetHouseNumber()
: iStreet(""),
iHouseNumber("")
{}
CStreetHouseNumber(string aStreet, string aHouseNumber)
: iStreet(aStreet),
iHouseNumber(aHouseNumber)
{}
string iStreet;
string iHouseNumber;
};
map<string,map<string,vector<CStreetHouseNumber>*>*>* iData;
};
|
|
|
|
|
As the maps & vectors are dynamically created, the wrapper object may be on the stack, but its data will be on the heap, as it will be dynamically allocated. And that will apply to classes allocated by dynamically allocated classes allocated by... (etc).
Iain.
|
|
|
|
|
Thank you very much for your response!
Manu
|
|
|
|
|
The map class gets data from you and gives it back to you whereever it stores said data in encapsulated within the map-class.
Whether you construct the map-object on stack or in heap is irrlevant, as the same code for datastorage will be called in both cases.
The implementation can be controlled by you by giving it an appropriate allocator for your data.
The default allocator uses the heap, afaik.
You can read the code yourself, it comes with VC. On my VC2005 it in
C:\Program Files\Microsoft Visual Studio 8\VC\crt\src\map
Though I speak with the tongues of men and of angels, and have not money, I am become as a sounding brass, or a tinkling cymbal. George Orwell, "Keep the Aspidistra Flying", Opening words
|
|
|
|
|
Hi,
What is the difference between DS_CONTROL and WS_EX_CONTROLPARENT? I know DS_CONTROL will remove the WS_CAPTION and WS_SYSMENU styles from the dialog. But I dont know if any other differences are there.
Thanks in advance.
- NS -
|
|
|
|
|
Off memory, DS_CONTROL style governs what happens when you reach the end of the tab order of controls in a dialog. If it's not set, the tab order will wrap around. If it *is* set, the tab will pass to a window governed by the dialogs parent window.
The documentation for WS_EX_CONTROLPARENT pretty much tells a normal window to do the tab order thing for it's children. I bet if you look at a normal dialog using spy++ you will see this bit is set.
Iain.
|
|
|
|
|
But I am very much confused with this DS_CONTROL
I have a dialog havning two buttons. And another dialog with two edit boxes. And in the OnInitDialog I have as follows.
m_dlgctrl.Create( m_dlgctrl.IDD, this );
ModifyStyleEx( 0, WS_EX_CONTROLPARENT );
m_dlgctrl.ModifyStyleEx( 0, WS_EX_CONTROLPARENT );
m_dlgctrl.ModifyStyle( DS_CONTROL, 0 );
Now the child dialog has no DS_CONTROL. But the tab order quite fine. This proves that DS_CONTROL has no influence in tab setting?
- NS -
|
|
|
|
|
I can do no better than to point to the explanation on Raymond Chen's blog (one of the first few google results for DS_CONTROL, by the way...
http://blogs.msdn.com/oldnewthing/archive/2004/07/30/201988.aspx[^]
"When you set the DS_CONTROL style on a dialog template (or set the WS_EX_CONTROLPARENT extended style on a regular window), a bunch of new rules kick in."
I hope his article can help!
Iain.
|
|
|
|
|
Ya. I have already read that. I understood nothing more... That is why I posted this doubt.
- NS -
|
|
|
|
|
I am creating an ownerdraw listbox. In DrawItem function I want to draw text. There's a code snippet in MSDN that is a little bit strange:
It uses this code to retrieve the text of current item.
LPCTSTR lpszText = (LPCTSTR) lpDrawItemStruct->itemData;
I think it's wrong because a user might add custom data to items of the control and it's logical that itemData member refers to that data, anyway it doesn't work for me. I used this code which works just fine:
GetText(lpDrawItemStruct->itemID, str);
Is this ok?. If not, then is there any better way of finding text of current item in DrawItem ?
// "Life is very short and is very fragile also." Yanni while (I'm_alive) { cout<<"I love programming."; }
|
|
|
|
|
Reading the MSDN documention about the DRAWITEMSTRUCT will give you the information about itemData. Hope you will...
Anyway the second method you used is not wrong.
- NS -
|
|
|
|
|
NS17 wrote: Reading the MSDN documention about the DRAWITEMSTRUCT will give you the information about itemData.
I did, and that's the reason of this question. It says something that seems to be wrong to me:
from MSDN:
itemData
For a combo box or list box, this member contains the value that was passed to the list box by one of the following:
CComboBox::AddString
CComboBox::InsertString
CListBox::AddString
CListBox::InsertString
this description with the snippet try to prove the string added can be found in itemData variable. I'm wondering at the moment, whether it differs if a list box has HAS_STRING style or not. Mine has and the itemData has not the string.
I'm completely confused
// "Life is very short and is very fragile also." Yanni while (I'm_alive) { cout<<"I love programming."; }
|
|
|
|
|
Hamed Mosavi wrote: it differs if a list box has HAS_STRING
Yes.
- NS -
|
|
|
|
|
A different question why you dont use of ListCtrl instead ListBox?
|
|
|
|
|
I like listbox because of its simplicity. But could you please point out the advantage of listctrl that made you to ask so?
- NS -
|
|
|
|
|
Instead my choice is Listctrl and ListBox is simple to use but its limited.
|
|
|
|
|
Hamid. wrote: but its limited.
That's true...
- NS -
|
|
|
|
|
Hamid. wrote: why you dont use of ListCtrl
Because all I need is a list of names.
CListCtrl has been designed to do more, like icons, different views(like report), good in-place edit, etc. and more flexibility cause more complexity, so one should spend a lot more time and write more codes to do the same work that could be easily done by a ListBox.
Now that I don't need those features, why should I go the hard way?
// "Life is very short and is very fragile also." Yanni while (I'm_alive) { cout<<"I love programming."; }
|
|
|
|
|
Hamed Mosavi wrote: Now that I don't need those features, why should I go the hard way?
I agree. It was an odd suggestion.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Your method seems fine to me - but have a look at LBS_HASTRINGS to be sure.
My suspicion is that the example snippet is just storing a pointer to some text in itemData in order to have something simple to draw. There's nothing to stop you have your code numbers in it, or neglecting it completely.
Iain.
|
|
|
|