|
Hi All This is My First Post in this Group (Hope i Will Get To Learn a lot Here)
Here is my Query
I want a Browser Helper Object in ATL.
(Any FAQ's Link Will be Much Appriciated)
Is it Possible To Change the Contents of a Browser(window) Through the BHO's ?
I want to UnderLine a few Keywords that are in the WebSite being Displayed in Browser Window , Is It Possible ?
Thanks All 
Live as if your were to die tomorrow. Learn as if you were to live forever.
-Mahatma Gandhi
|
|
|
|
|
IHTMLDocument2->write will let me write in the browser window.
i'll get the HTML parse it add a few tags and write it back
is it ok or am i dreaming
Any Comments/Suggestions ?
Live as if your were to die tomorrow. Learn as if you were to live forever.
-Mahatma Gandhi
|
|
|
|
|
I have a lot of source code where CWinThread is used. How to change CWinThread to a WTL project? Thank you.
Freehawk
|
|
|
|
|
I'm writing a VT100 ActiveX Control,
I add an Atl Control class, "CAVTCtrl", 2 Atl objects
"CEmul" and "CTerm".
the 2 Atl objects are created inside "CAVTCtrl" (aggregate) , "CEmul"
handle input stream in VT100 format, decode them in to a buffer, "CTerm" read the buffer, and display on terminal window.
the CEmul implements a _IEmulEvents interface,
CTerm implements _ITermEvents, to dispatch events to CAVTCtrl and User Applications,
But CAVTCtrl is already a event sender, can't be defined as event receiver.
So, how to dispatch events from CEmul and CTerm to CAVTCtrl, and expose the _ITermEvents _IEmulEvents connection points?
|
|
|
|
|
How might I reference the iterator that's currently activating the function object, while inside the function itself? I'm trying to do "in-place" update.
Here's some code to demonstrate what I mean. (namespace and '#include' statements were provided.)
typedef map<const string, string, less<string> > MapStr;
typedef pair<string, string> PAIR_KV;
class FnObj
{
public:
void operator() (const MapStr::iterator& it);
};
int main()
{
MapStr mapStr;
MapStr::iterator iterB = mapStr.begin(), iterE = mapStr.end();
for_each(iterB, iterE, FnObj());
return 0;
}
void FnObj::operator() (const MapStr::iterator& it)
{
MapStr mapStr;
PAIR_KV PAIR;
if((*it).first == "Old Key")
{
mapStr.erase(it);
PAIR.first = "New Key";
PAIR.second = "This is the value of the new key";
mapStr.insert(PAIR_KV(PAIR.first, PAIR.second));
}
}The compiler is not happy with the above code.
Any insight is appreciated.
William
Fortes in fide et opere!
|
|
|
|
|
The functor's argument is a reference to the object pointed to by the iterator, not the iterator itself, so that's the source of your compile errors. In your case the argument would be pair<const string,string>&. However, the VC 6 docs specifically say the function must not alter the object
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | 1ClickPicGrabber New v2.0! | RightClick-Encrypt
Kosh reminded me of some of the prima-donna programmers I've worked with. Knew everything but when you asked them a question; never gave you a straight answer.
-- Michael P. Butler in the Lounge
|
|
|
|
|
Thanks for replying.
OK, I can settle for not altering the key, but being able to change the value of the second argument, does nothing as far as altering the structure of the map (which is what "in-place" update seeks to do).
William
Fortes in fide et opere!
|
|
|
|
|
You may not modify the structure of the container you are iterating with for_each. The reason is that you may invalidate iterators which for_each is holding a reference to.
NEVER modify containers structurally while inside iterating functions such as for_each.
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
Thanks for replying.
As stated in my earlier reply, I can understand the reason for NOT modifying the keys in a map (while using algorithms such as "for_each"), but altering the value of the second argument does NOT alter nor invalidate any of the map's iterator, and that notion therefore shouldn't be applicable to those sort of activities.
William
Fortes in fide et opere!
|
|
|
|
|
Well, but it is possible to alter the value..  That's why you get a reference to the container<T>::value_type instead of an iterator. In the map case, the value_type is a pair consisting of the key and value.
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
Thanks again for replying.
That being the case, I see little value in using the "for_each" algorithm when dealing with maps (perhaps with ANY container, since all the user is relegated to, is a set of "read only" type activities). You certainly seem to have more freedom in doing anything with ANY container by simply using the C++ "for" statement.
 to the STL "for_each" algorithm.
William
Fortes in fide et opere!
|
|
|
|
|
What are you talking about? As Michael Dunn pointed out, you get a pair<const string,string>& as an argument to your functor. If you want to modify the value, just do arg.second = whatever_you_fancy.
for_each does not relegate the user to read only types.
struct addone {
void operator()(std::map<int, int>::value_type & arg) const {
arg.second++;
}
}; What is so read only with that?
You cannot modify the key at all since it may break the ordering restrictions of the associative container - this by design so that these containers can be implemented using hash tables or search trees. You cannot modify the container itself because it could invalidate iterators for the algorithms in ways that cannot be anticipated.
What you must have is an extra level of indirection because of the associativity rules - in this case the container itself. Since you are modifying order (keys) - not values - you need to handroll your own algorithm.
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
Thanks for replying.
Prior to my response, I had done this.
void FnObj::operator() (const PAIR_KV& PA)
{
PAIR_KV PAIR = PA;
if(PAIR.first == "Old Key")
{
PAIR.second = "This is the NEW value for the old key";
}
}As you can see, I typed in a new string value to the old key second argument. When I ran the program and displayed its content, the new string value did not get shown. The old value was still in the map.
Unless I am absolutely not supposed to do ANYTHING inside the function object routine, this is what I'm talking about.
William
Fortes in fide et opere!
|
|
|
|
|
Of course nothing happened with the old values in your map. Look at what you're doing! You're accepting a PAIR_KV by const reference. You then assign it to a stack based PAIR_KV object. You get a copy! You are modifying the local copy on the stack.
Do this instead
typedef map<string, string> MapStr;
void FnObj::operator() (MapStr::value_type& PA) {
if(PA.first == "Old Key") {
PA.second = "This is the NEW value for the old key";
}
}
Why did you have a const string as key to begin with? Look, I seriously believe that you should get a good book on STL. I recommend Generic Programming and the STL: Using and Extending the C++ Standard Template Library by Matthew H. Austern, ISBN 0201309564.
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
You are great on the giving of advice, but very poor on the testing of your own advice, because if you had tested the advice you were giving, you would have discovered they DON'T WORK. I know they don't work because I applied what you suggested and ended up (the latest) with 6 errors!!
Moreover, if you had looked closely, you would have seen that I had:
typedef pair<string, string> PAIR_KV; That's my "value_type" for the map that you keep talking about so much. It's there! SEE! It's there! I don't need your "MapStr::value_type&" suggestion, but I used it anyway just to see if it would work, ... and IT DIDN'T!! So much for your well-informed advice.
Yes, I had tried removing "const" from all the places they were being used and ended up with errors of one kind or another, and even tried using the reference straight from the parameter list of the function object "operator()" (without creating one on the stack). That didn't work either (meaning, it produced several errors)!
If you had done the various testings as I did, you would have found that "for_each" is just not a good algorithm for dealing with maps. It's obvious you didn't know that, based on the incorrect advice you have been giving.
NONE of the advice you have given so far worked. NONE! But there you are, telling me to go read up on certain STL books. FYI, I do my share of reading, and practicing with the STL almost every day. I certainly DON'T NEED another one of your gratuitous advice. KISS OFF!!
William
Fortes in fide et opere!
|
|
|
|
|
#include <map>
#include <iostream>
#include <utility>
#include <algorithm>
typedef std::map<int, int> IntMap;
struct addone {
void operator()(IntMap::value_type& v) const {
v.second++;
}
};
struct print {
void operator()(IntMap::value_type& v) const {
std::cout << "first = " << v.first << ", second = " << v.second << std::endl;
}
};
int main(int argc, char* argv[])
{
IntMap map;
map.insert(std::make_pair(1, 1));
map.insert(std::make_pair(2, 2));
map.insert(std::make_pair(3, 3));
map.insert(std::make_pair(4, 4));
map.insert(std::make_pair(5, 5));
std::for_each(map.begin(), map.end(), print());
std::for_each(map.begin(), map.end(), addone());
std::for_each(map.begin(), map.end(), print());
return 0;
} I'm just being honest; Do yourself a favor - stop whining and pick up an STL book.
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
KISS OFF!!
Who needs your crappy little "int" addone sample?
I've had enough of your unworkable samples in the past. I don't need anymore.
If you didn't understand my last message, it states, "I do my share of reading just about everyday." I DON'T NEED you to tell me what to do.
Take your crappy little "map.insert" sample and SHOVE IT!!
It wouldn't hurt for you to do some reading of your own also. You clearly need it. All those unworkable advice you've been giving. You definitely need to do a lot of reading yourself.
William
Fortes in fide et opere!
|
|
|
|
|
At least you're entertaining. 
--
You copy and paste yourself into my brain.
You always find your way back into my brain.
|
|
|
|
|
Even that you lack.
William
Fortes in fide et opere!
|
|
|
|
|
Oh, please guys, continue fighting. This is very funny 
"semper aliquid haeret", Bacon.
-- Sebastián.
|
|
|
|
|
Hey, I'm not fighting.
--
You're entertaining at least.
|
|
|
|
|
<br />
#include <map><br />
#include <iostream><br />
#include <utility><br />
#include <algorithm><br />
#include <string><br />
<br />
<br />
typedef std::map<std::string,std::string> StringMap;<br />
<br />
struct update<br />
{<br />
void operator() ( StringMap::value_type& v ) const<br />
{<br />
if ( v.first == "second" )<br />
v.second = "replaced value";<br />
}<br />
};<br />
<br />
struct print<br />
{<br />
void operator() ( StringMap::value_type& v ) const<br />
{<br />
std::cout << "first = " << v.first << ", second = " << v.second << std::endl;<br />
}<br />
};<br />
<br />
int main( int argc, char* argv[] )<br />
{<br />
StringMap testMap;<br />
<br />
testMap.insert( StringMap::value_type("first", "1") );<br />
testMap.insert( StringMap::value_type("second", "2") );<br />
testMap.insert( StringMap::value_type("third", "3") );<br />
testMap.insert( StringMap::value_type("fourth", "4") );<br />
testMap.insert( StringMap::value_type("fifth", "5") );<br />
<br />
std::for_each(testMap.begin(), testMap.end(), print());<br />
std::for_each(testMap.begin(), testMap.end(), update());<br />
std::for_each(testMap.begin(), testMap.end(), print());<br />
<br />
return 0;<br />
}<br />
However, as you know (from your comments in your original post), the code in the "update" functor is basically doing a find. However, since the for_each does a loop through all elements of the map, this is much less efficient than doing an actual find. If you need to do single updates to elements in a map which have particular key values, it would normally be better to just do the find and then update the element. The for_each algorithm is really only appropriate if you need to access every element in the container.
Best regards,
John
|
|
|
|
|
Thanks for replying.
Your sample does work.
William
Fortes in fide et opere!
|
|
|
|
|
jbarton wrote:
If you need to do single updates to elements in a map which have particular key values, it would normally be better to just do the find and then update the element.
That depends a little on how many values you are updating. If you are updating few elements, then the approach you mention is more efficient. But if the number of values are many, then an iteration is faster. Assuming that the map is implemented as a balanced search tree, you need to find out how O(k * log(n)) relates to O(n), where k is the number of values to update, and n is the number of elements in the map. Of course, if it's a hashmap, then the approach you mention is most likely faster for basically all k (unless, of course, the hash algorithm is very slow).
I guess it would be advantageous to encapsulate this algorithm into its own function, and let itself adapt to the problem size automatically. But hey, how would I know? I just post faulty samples and is a retard according to some.
--
You're entertaining at least.
|
|
|
|
|
I think the idea of iterating through the map to update multiple elements has merit. If (for instance) I want to update the data associated with all keys that match a particular pattern, there really isn't any way that I could do it without iterating through all elements in the map.
When I have a list of specific key values whose data I want to update, I find it difficult to set up a functor that efficiently checks for these key values and then updates the associated data values. It may be possible using another map or hash within the functor to lookup the key value and then get the replacement value. With only simple if / else if comparisons, I think that the overhead of the functor would probably remove any advantage gained by not using find on each key value.
Unless the program I was writing was running too slowly and by profiling I found it to be due to using find to update the map, I would probably stick with using find.
If you know of a better way of writing this functor, let me know. I am always interested in hearing other approaches.
Best regards,
John
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
