|
It would help if you used the <> buttons below, so we could see your template arguments and includes.
What on earth is m_lstPy ? Are you trying to use STL to do a find within a string, or what ?
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
During last 10 years, with invention of VB and similar programming environments, every ill-educated moron became able to develop software. - Alex E. - 12-Sept-2002
|
|
|
|
|
OK. Try declaring pos as
vector<CString>::const_iterator pos;
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I've got an app, generated with the ATL app wizard in VC7.
Now it was compiling fine, until I added a CSting object to a function, and now it gets upset, saying it does not know what one is, yet I know CString is in ATL now.
Any ideas what could be happening? I'm getting error C2065 - undeclared identifier.
Anyone know which header file its in so I can include it explicitly?
|
|
|
|
|
It's quite obvious - and mentioned in the help for CStringT 
#include <atlstr.h>
Bjørn.
|
|
|
|
|
Bjoern Graf wrote:
It's quite obvious - and mentioned in the help for CStringT
Ahh yes 
Must remember to turn my brain on.
|
|
|
|
|
Also, if you even include <atlmisc.h> (which defines the WTL CString, CRect, etc.) then it may conflict with the ATL7 version. If you want to use the ATL7 CString AND you still need <atlmisc.h> then do the following in stdafx.h:
#define _WTL_NO_WTYPES
#define _WTL_NO_CSTRING
#include <atlmisc.h>
Faith. Believing in something you *know* isn't true.
|
|
|
|
|
It worked without, but I'll use it anyway.
Thanks,
Giles
|
|
|
|
|
I've worked a lot with COM and ATL (thank goodness for ATL), but I'm not clear on what WTL is. I've used templated classes like CWindow and what not. Is that WTL and I've been using it unknowningly? I plan on using all that stuff for a current project I'm working on, but would like to use WTL.
I'd appreciate any comments. The MSDN documents don't really talk much about WTL as a topic, so I'm guessing it's just certain classes within ATL, but I could be wrong.
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
Does this article help? Introduction to WTL - Part 1[^]
HTH 
Nick Parker
The greatest lesson in life is to know that even fools are right sometimes. - Winston Churchill
|
|
|
|
|
Yes, very. Thanks!
"Well, I wouldn't say I've been missing it, Bob." - Peter Gibbons
|
|
|
|
|
WTL tries to wrap many of the basic features of the Win32 library in the same way that ATL started. WTL is a framework much like MFC but it is a lot lighter. You can incorporate WTL into your existing ATL ActiveX components or use it as its own framework to create a standalone application without ATL.
There are two main problems with WTL:
1) It is not supported by Microsoft. It was released as a sample framework that was a demostration of what could be done with templates. Since it is not "officially" supported by Microsoft there is not any official documentation for it. However there are tons of newsgroups and places where you can go to get help with WTL. Plus it is good for you to look through the WTL source code and learn how to expand it yourself .
2) It is not as full featured as MFC. So there is no official document / view architecture classes or anything like that. Mainly just simple wrapper classes around the major portions of the Win32 API. Once again, there are many places where you can go to get WTL resources on teh internet and tons of people that are willing to help support this tool.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul Watt (kilowatt) wrote:
no official document / view architecture classes
And that's a bad thing?
|
|
|
|
|
Well it all depends on what you like.
I personally think that it is a very good concept, but I dont think that MFCs version was executed very well. I have often thought of writing my own for WTL to see if I could do better .
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
On the contrary. MFC Doc/View is way too file centric and way to restrictive. I like the Smalltalkish MVC model a LOT better, where the model isn't file centric.
--
Please state the nature of your medical emergency.
|
|
|
|
|
I am interested in the MVC model, do you have any good links, or should I just google to find some?
Also, Microsoft strongly believes in the Document centeric model. If you look at all of their current software, Office being the main model, they are all document centric. As a general rule they do not do MDI interfaces anymore (development environments excluded).
If you have two documents, you will have two top level windows open on the task bar to allow you to switch between the two documents a lot easier.
So possibly this will explain the strong file centric development model in MFC.
(thats actually a bunch of BS because WTL does this the proper way with the Multi-threaded SDI model )
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Paul Watt (kilowatt) wrote:
I am interested in the MVC model, do you have any good links, or should I just google to find some?
I don't have any links on the top of my mind. I was acquainted with the MVC paradigm in a OO-course using Smalltalk (I chose not to say model to avoid confusion - the M in MVC stands for Model  ). The entire GUI was built using this paradigm. Anyhow, MVC is a fairly well-known OO-concept in GUI modelling. I think a Google search would give you more than you can read in a life time.
MVC stands for Model View Controller. The View(s) observe(s) a Model and updates itself for each change in the Model. The Controller(s) control the Model and the View. The Controller(s) also observe(s) the Model and the View and may update accordingly.
Example scenario: Model = geographical map data. View = graphical representation of map data. Controllers = scrollbars for panning and buttons for zooming in and out. The scrollbar Controllers observes the Model and the View - thus it is able to determine how large the thumbs should be. When the thumbs are moved, the scrollbar Controller notifies the View that it should depict another portion of the map. It's all very simple really, it's just a division of responsibility to make it easier and more flexible.
If you haven't noticed, Microsofts Document is equivalent to the Model, and the View is equivalent to View+Controller. It's easy to see that the Document/View isn't half has flexible as "pure" MVC. I don't know why Microsoft settled for a less powerful paradigm - nobody bothered to question it perhaps?
Paul Watt (kilowatt) wrote:
Also, Microsoft strongly believes in the Document centeric model. If you look at all of their current software, Office being the main model, they are all document centric. As a general rule they do not do MDI interfaces anymore (development environments excluded).
Yes, but Office is per se file-centric. Everything you do in MS Office results in a file. What if the "document" is reading data from the network never intended to be docified? In situations like that, the doc-template stuff is really mind-boggling. And all those weird frame/view/document "protocols"? Not very intuitive at all. I get the shivers everytime I do it.. 
Paul Watt (kilowatt) wrote:
thats actually a bunch of BS because WTL does this the proper way with the Multi-threaded SDI model
WTL does very little - but what it does is proper and well done. MFC does a whole lot, but misses the point 90% of the time. But that's just my not too objective oppinion.
--
Please state the nature of your medical emergency.
|
|
|
|
|
Heath,
Here is another good link, especially with documentation if you are going to be doing anything on WTL. The WTL Documentation Project[^] here at Code Project.
Nick Parker
The greatest lesson in life is to know that even fools are right sometimes. - Winston Churchill
|
|
|
|
|
Can somebody show me how should I work with an CComPtr pointer. Are there any web links wich I can follow.
|
|
|
|
|
CComPtr is a SmartPointer wrapper class specifically designed for COM objects. So when your smart pointer goes out of scope, it will automatically call Release on your object. It is very simple to use.
First declare a CComPtr to wrap one of your objects:
<br />
CComPtr<IDataObject> spDataObj;<br />
Now you can use spDataObj anywhere that you would normally use a pointer to the interface. You do not need to worry about casting or dereferencing or anything like that it is completely transparent.
<br />
IUnknown *pUnk;<br />
...<br />
pUnk->QueryInterface(IID_IDataObject, &spDataObject);
spDataObj->GetData(...);
Some other cool things to know are the Attach and Detach members. This will allow you to attach an existing interface pointer to the CComPtr without addrefing it internally, and the Detach method will allow you to remove the internal interface pointer without releasing it.
Other than that it should be pretty straight forward, and you may also want to checkout CComQIPtr. That smart pointer object will allow you to query for the interface on assignment, so it will save you one step when you are setting up your pointers.
Good Luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Also, check out CComPtr::CoCreateInstance (or was it CreateInstance only?)
--
Please state the nature of your medical emergency.
|
|
|
|
|
it is CoCreateInstance. CreateInstance is with _com_ptr_t.
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
|
That does look cool.
Have you used it?
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Not yet. I browsed through the documentation and found that it's excellent in theory.
What's really excellent is that you don't need a separate tool like yacc or bison - you just need C++/STL! And the quality seems very high. It's being submitted to the boost library/committers so it has to be high quality.
They're also working on a strict LL(1) parser (more efficient in terms of speed and memory) for every day grammars. What's lovely with LL(k) is that it can take on complex grammars like that of C++.
Also, if I understood the docs correctly, it also has support for symbol management with complete scoping! They even claim that they'll implement the different scoping rules found in C++ - including König lookup.
If I need to write a parser/compiler again, I'll sure try this library. It looks very promising.
--
Please state the nature of your medical emergency.
|
|
|
|
|
from the page:
... The Spirit framework enables a target grammar to be written exclusively in C++. Inline EBNF grammar specifications can mix freely with other C++ code and, thanks to the generative power of C++ templates, are immediately executable. In retrospect, conventional compiler-compilers or parser-generators have to perform an additional translation step from the source EBNF code to C or C++ code. ...
WOW !!!!! Writing the grammars in C++ !!! Inline EBNF grammar specifications mixed freely with other C++ code !!!!!!!!!
Using C++,STL and template metaprogramming !!!!!!!! 
Now , when I have the time I'll test it, but it appears that it ROCKS !!!
Thanks a lot for the link !!! Added instantly to my Favourites
p.s: I didn't have compilers in college , but I studied myself a bit
Cheers,Joao Vaz
And if your dream is to care for your family, to put food on the table, to provide them with an education and a good home, then maybe suffering through an endless, pointless, boring job will seem to have purpose. And you will realize how even a rock can change the world, simply by remaining obstinately stationary.-Shog9
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
