|
For the verb, try running IE explicitly.
::ShellExecute(m_hWnd, "open", "iexplore http://www.codeproject.com/", "", "", SW_SHOW)
There might be another way also, and of course this would only work if IE is included in the path, so you may want to check the registry for validating this beforehand.
Jeremy L. Falcon<nobr>
Homepage : Sonork = 100.16311
"But everybody darlin' sometimes bites the hand that feeds."
"Remember in this game we call life that no one said it's fair."
"Just because you're winnin' don't mean you're the lucky ones."
Song: Breakdown - Album: Use Your Illusion II - Artist: Guns N' Roses
|
|
|
|
|
related-- (if you are invoking IE explicitly
using ShellExecute)
IE has some command line options
see MS KB article Q178058
try the -new option
but as long as you are limiting to IE,
go all out and use the exposed automation...
|
|
|
|
|
Use "-new" command line option.
Best wishes,
Hans
|
|
|
|
|
Do you know how could i use the equivalent of C's escape sequences in VB to write strings like this: "a1 \"b1\" c1"?
rechi
|
|
|
|
|
Shame on you for cross posting! I'll answer this in the VB forum.
Jeremy L. Falcon<nobr>
Homepage : Sonork = 100.16311
"But everybody darlin' sometimes bites the hand that feeds."
"Remember in this game we call life that no one said it's fair."
"Just because you're winnin' don't mean you're the lucky ones."
Song: Breakdown - Album: Use Your Illusion II - Artist: Guns N' Roses
|
|
|
|
|
Thanx for your answer!
It's not an usual practice for me to cross-post; just an exception. Sorry!
rechi
|
|
|
|
|
Mmmhh ... In a dialog MFC app, I have a thread MainThread in which i start a thread ChildThread. The ChildThread has a priority set to LOWEST, and the MainThread set to ABOVE_NORMAL. However, when I debug step by step, the ChildThread seems to run with a greater priority than the MainThread(100/1 instructions ratio). Why ?
~RaGE();
|
|
|
|
|
How have you determined this ratio? Please note that it is higly unlikely you're calculating any significative figure within a steyp by step debugging process. Also, the number of instructions per second executed by a thread does not only depend on its priority, but also on the frequency of yielding operations it performs (ops for which the system deems it appropriate to pass the control to another thread till they complete, such as IO APIs.)
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
How have you determined this ratio?
I determined the ratio this way : I have two 'for' loops in the Child threads, doing some stuff. So when I launch the ChildThread from within the Main, it starts and finishes the first loop in the CT, does one instruction in the MT, does the second loop in the CT, and return for one instruction in the MT. Since the 'for' limit is 102 in both 'for' loops, I had my ratio 
Joaquín M López Muñoz wrote:
Please note that it is higly unlikely you're calculating any significative figure within a steyp by step debugging process. Also, the number of instructions per second executed by a thread does not only depend on its priority, but also on the frequency of yielding operations it performs (ops for which the system deems it appropriate to pass the control to another thread till they complete, such as IO APIs.)
That´s exactly what i wanted to know when posting my thread. I thank you very much ...
~RaGE();
|
|
|
|
|
Probably a misimpression caused by debugger. How are you measuring this performance difference? Is the problem that the main thread is sitting in single step mode while the child is executing?
Also, be aware, setting priority is not the same as setting speed. It simply means that when given a choice between the 2 threads waiting for the same resource, the higher priority thread will go first (within limits).
|
|
|
|
|
According to the MSDN On-line, the "Programmer's Reference" installs, by default, a command-line utility called Bitmap.exe as part of ICM 2.0; I am in need of that utility. I've been unable to determine from where this program is installed (i.e., Platform SDK, DDK, Etc...) but I do know that I do not have it on my machine and the MSDN On-line does not indicate where this program can be downloaded from. 
Any ideas from what CD I can get this? 
Here's the link to the MSDN page that references this program
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/icm/icm_16pc.asp
TIA,
D.
|
|
|
|
|
It is included in the Platform SDK.
On my pc it is in the "Platform SDK install Folder\bin" folder...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Thanks for the response. Shortly after having posted this message, we discovered it as well on the Platform SDK CD.
Unfortunately, it does not resolve our issue, even if it's a really cool utility.
Thanks again,
D.
|
|
|
|
|
Hi guys, whenever I place the following code into a module within my project, I get a linker error
(error LNK2001: unresolved external symbol _cmc_logon@36)
The offending piece of code is...
::cmc_logon(NULL,NULL,NULL,NULL,0,CMC_VERSION,NULL,&Session,NULL);
where I have set Session as CMC_Session Session.
I've already included xcmc.h into my project, any ideas on why I'm still getting a linker error?
Just another wannabe code junky
|
|
|
|
|
is there any .lib files missed in Linker options?
Renjith-The CPian.
|
|
|
|
|
Renjith - The CP ian wrote:
is there any .lib files missed in Linker options?
Yep...thanks Renjith  I'm slightly embarrassed now.
Regards
Senkwe
Just another wannabe code junky
|
|
|
|
|
Hi everybody,
Q1a: Why does a dialog based MFC app take appr. 1200KB of working memory?!
Q1b: I created an exact copy of this MFC dialog app with Delphi with the exact same functionality and it only aquires 150 KB of RAM... How come Delphi (Pascal) outperforms the living sh*t out of a regular C++ app?
Q2: Within my MFC app I wish to allocate an array of let's say 1 000 000 Things where Things defined as
class Things
{
int m_nType;
int m_n123[3];
}
I do it like this
ptr_things = new Things[1000000];
This, as far as I've understood it, allocates memory this way:
1000000 * (4 bytes + (3 * 4 bytes)) having integers with 4 bytes, correct?
Now, I can see in the task manager (w2k) that the memory used by the app increases violently when this line of code is executed.
BUT, when doing exactly the same thing (not quite, i statically declare a 1000000 array) in Delphi the memory increases only by a few hundred kilobytes.
Can anyone explain this to me please? Feels weird to develop with C++ when Delphi seems to rock the world! Is there another way to allocate more efficiently?
Q3: If I have a lengthy process where I do something like this...
int nSomeStuffCounter = 0;
int nNumberOfLoops = 243;
CString str;
for (int a = 0; a < 3; a++)
for (int b = 0; b < 3; b++)
for (int c = 0; c < 3; c++)
for (int d = 0; d < 3; d++)
for (int e = 0; e < 3; e++)
{
DoSomeStuff();
nSomeStuffCounter++;
str.Format("%d%% done", (int)(((double)nSomeCounter/nNumberOfLoops)*100));
wndStatusText.SetWindowText(str);
}
... it takes very (!) long time for the process to finish where as I remove the status reporing it works quickly. Trivial enough... BUT how can I report the progress of a lengthy process without slowing the process itself down too much? And I don't wanna hear progress bars... they kill the performance of any app. Or am I wrong? Can threading help me here...?
Thx for any advice,
/Tommy
|
|
|
|
|
Tommy Svensson wrote:
Q1a: Why does a dialog based MFC app take appr. 1200KB of working memory?!
Q1b: I created an exact copy of this MFC dialog app with Delphi with the exact same functionality and it only aquires 150 KB of RAM... How come Delphi (Pascal) outperforms the living sh*t out of a regular C++ app?
A1a: MFC is a class library which resides in DLLs. Windows will load these DLLs when you run your app.
A1b: I don't know jack about Delphi, but its probably built on top of the WinAPI. MFC apps add a layer in between you and the API. As far as out performing the living sh*t out of a regular c++ app, I would have to see the performance stats to believe it. Try writing a windows app with the API in c++ and see which one wins.
Tommy Svensson wrote:
Q2: Within my MFC app I wish to allocate an array...
BUT, when doing exactly the same thing (not quite, i statically declare a 1000000 array) in Delphi the memory increases only by a few hundred kilobytes.
I don't believe this for a second. Besides, a class is different than an array so I wouldn't expect it to be the same. I just doubt that Delphi only allocates a few hundred kb.
Tommy Svensson wrote:
Feels weird to develop with C++ when Delphi seems to rock the world!
Someone kick this guy in the crotch for me.
Tommy Svensson wrote:
Q3: If I have a lengthy process where I do something like this...
A3: If you want to report the progress, you're going to have to sacrifice a little speed. GDI is not the fastest thing in the world so updating text or a progress bar using GDI is going to suck some speed out. Threading will help, but it will still be slower than having no updates at all.
Tommy Svensson wrote:
Thx for any advice,
This is a c++/mfc forum, I suggest you take the "Delphi kicks MFC a$$" attitude elsewhere.
Jason Henderson
quasi-homepage
articles
"Like it or not, I'm right!"
|
|
|
|
|
Jason Henderson wrote:
Tommy Svensson wrote:
Feels weird to develop with C++ when Delphi seems to rock the world!
Someone kick this guy in the crotch for me.
I'm not saying I favour Delphi; what I AM saying is that Delphi apps at first sight appears to be smaller, at least as efficient as VC++ apps and requires less working memory... that's all. And I was just waiting for a serious  answer to prove my discoveries wrong because I know, by rumours and democratic majority, that VC++ should be the thing rocking the world.
Jason Henderson wrote:
This is a c++/mfc forum, I suggest you take the "Delphi kicks MFC a$$" attitude elsewhere.
This is a Visual C++ forum and I do believe my posts regarding VC++ belong here, don't you think?
Be well now,
/T
|
|
|
|
|
Tommy Svensson wrote:
Feels weird to develop with C++ when Delphi seems to rock the world!
Then, why are you trying to develop in C++ ?
Tommy Svensson wrote:
the memory used by the app increases violently when this line of code is executed
Did you really expect a "Hey, you won´t fool me, guy !" dialog to appear on the screen ?
Tommy Svensson wrote:
BUT, when doing exactly the same thing (not quite, i statically declare a 1000000 array) in Delphi the memory increases only by a few hundred kilobytes.
The difference is in the "not quite" and in the "array". You have actually constructed a million objects, and therefore used memory for that. Declaring an array just say the heap not to use a range of addresses which will be used to store data. Try filling your Delphi array with something, and watch how memory app increases ...
Tommy Svensson wrote:
BUT how can I report the progress of a lengthy process without slowing the process itself down too much
Do it in Delphi.
~RaGE();
|
|
|
|
|
Rage wrote:
Then, why are you trying to develop in C++ ?
I only said Delphi seemed to rock the world. I know it shouldn't but all I saw was telling me it was.
So, what I wanted you to tell me [gee, why wasn't I more clear about this], was some facts to show me just how much better VC++ are.
Cheers,
/T
|
|
|
|
|
Q2. Sounds like Delphi is doing a virtual allocation. There is code available at CP here to do the same thing in C++, I just can't find the url.
Q3. Your updating the status bar far too often. Try putting it 3 loops farther out, or an if condition that updates only every 1% increase etc. That will give a much smaller hit on performance.
Roger Allen
Sonork 100.10016
If I had a quote, it would be a very good one.
|
|
|
|
|
Tommy,
I have developed in both languages for several years now, Delphi more than C++, so I do have an answer for you:
As you've already read, MFC applications load the MFC DLL into memory when an application starts up, verse a Delphi application that's linked to the VCL statically (which only includes the code needed to run the application). If you build your Delphi application so you have to dist the packages, you'll see the same kind of result as an MFC application. If you really want to compare "apples to apples" you need to code a WTL Dialog application and then run them side-by-side.
In terms of "speed of execution" I am afraid you are incorrect. The last time I checked performance of a MFC Application verse a Delphi application, C++ ran 50 million lines of code per second verse Delphi's 20 million per second. When Borland, now Inprise, introduced that C++ Builder / Delphi IDE integration, they screwed the execution speed some how and Delphi actually became slower ( I believe Delphi originally executed at like 30 million lines/sec). This is code execution time, not compile time; Delphi's compiler smokes the daylights out of the C++ Compiler even with Precompiled Headers, I'll give Borland that much.
Regardless of that, speed of execution is why people like John Carmack develop in C++ and not Delphi, and why I've started to develop in VC++ myself. Well, that and the fact that I can hook directly into ANY new SDK MS releases without waiting for a "port" like Delphi developers do.
It's good see that you're "trying" to develop in VC++, keep at it; I too used to have similar questions when I made made the jump from Delphi, but once you've started to really dig into C++ you'll understand why "the dark side is more powerful".
Join us Tommy ... you don't know the power of the dark side. Let go of your feelings for Delphi, give in to your hatred for Microsoft. Join us.
<insert evil="" laughter="" here=""> 
( I know, I need a great deal of help ) 
D.
|
|
|
|
|
Thx for a serious reply!
My feelings for Delphi are long gone, but an old program I hade written using Delphi needed to be re-written using VC++. It was then that I discovered the differences that appeared to be favourable on behalf of Delphi.
Cheers,
/T
|
|
|
|
|
Tommy Svensson wrote:
Q1a: Why does a dialog based MFC app take appr. 1200KB of working memory?!
Because it loads the MFC dll, so there is a big price for entry into an MFC app. A Win32 app will be leaner, but more complex to code.
Tommy Svensson wrote:
Q1b: I created an exact copy of this MFC dialog app with Delphi with the exact same functionality and it only aquires 150 KB of RAM... How come Delphi (Pascal) outperforms the living sh*t out of a regular C++ app?
It doesn't. You're just not aware of where the 1200kb came from. A 'regular' C++ app and an MFC app are two different things. Try it using WTL or Win32 and you'll see differently.
Tommy Svensson wrote:
Feels weird to develop with C++ when Delphi seems to rock the world!
HAHAHAHAHAHAHAHAHAHAHAHAA !!!!! Go develop in Delphi then.
Tommy Svensson wrote:
Can threading help me here...?
No, not really. I would be reporting outside of that inner loop - no-one needs status reports THAT quickly. I'd report at about the 'c' loop.
Christian
I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002
Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. - Alex, 13 June 2002
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
