|
Maybe you could just create one simple source moudule containing the #include statement and the CHtmlEditView declaration to see if it compiles, and if not, if you get any other messages. Also it may help if you post the source here so we can see exactly what you have coded.
It's time for a new signature.
|
|
|
|
|
sunnyram wrote: so i added the header file 'afxhtml.h'...
To where?
"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
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I have a program that does some file operations. It uses the mainframe structure, but not the doc/view. (Doc/view didn't fit with what I was doing, for various reasons.)
The file operations are very simple and I do standard calls, but anything with files takes a very long time. Even just opening the file selection dialog takes a long time. And then selecting a file takes even longer, even though all I'm doing is storing the name of the selected file - might be 5 seconds to open, 5-10 seconds to select. The code:
CFileDialog fdlg
(true,
"bdb",
NULL,
OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT | OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST,
szFilter,
NULL);
fdlg.m_ofn.lpstrInitialDir = OutputDoc;
And then:
if (fdlg.DoModal() == IDOK)
{
strcpy(BINFODB, fdlg.m_ofn.lpstrFile);
pApp->AddToRecentFileList(BINFODB);
pApp->UpdateTitleBar(&(pApp->m_pMainWnd->m_hWnd));
}
In another part of the program I do some calculations based on input data, then write out some text files. This takes about 10 seconds on a fast computer. This program was originally written for DOS and much slower machines, yet it seems to take longer in the Windows version though the code for calculating and writing out the files is identical - literally identical (I put the DOS code in a DLL).
What could be causing the sluggishness? My computer has a 2.4 GHz duo processor with 4 gigs of RAM, and I'm running 64-bit Windows 7. This should be a fast machine.
Any thoughts on how I can speed things up? Right now I'm thinking I need to go back to displaying an hour glass during calculations, though this should be unnecessary with today's machines.
|
|
|
|
|
permutations wrote: literally identical (I put the DOS code in a DLL).
This could be part of the problem; if the code is compiled for 16 bit and DOS, the emulation needed for it to work at all would slow it down. Plus depending on the implementation of said emulation, it may be artificially making it run slower to better mimic the original platform.
You may want to consider porting the program to target Windows (32 bit at least).
|
|
|
|
|
It's compiled for 32-bit - sorry I didn't make that clear. The engine code was pulled from the original DOS program, and then recompiled for 32-bit Windows and packaged in a DLL. It's straight C code - should be efficient.
Anyway, this isn't the part that is running slowly. It's the file open dialog, which is strictly on the interface side and has nothing to do with the original DOS code. To adapt the DOS program I separated out the interface and the engine, put the engine in a DLL, and wrote a Windows interface. It's the file open dialog in the Windows interface that is slow as molasses, and it's such a simple call. I don't get it. Just bringing up the file open dialog box takes a really long time.
|
|
|
|
|
One crude technique I use sometimes is simply to break into the application periodically with a debugger and have a look at the call stack. Perhaps you'll get lucky and see the problem. A profiler would obviously be helpful and a lot more informative than my poor-man's profiler. Another classic is to simple scatter timing code throughout your code.
Steve
|
|
|
|
|
Hmmm... That's a good thought. I don't have a lot of experience with profiling and looking for inefficiencies in code. I guess the call stack would tell me if weird things are being called that I didn't realize.
> Another classic is to simple scatter timing code throughout your code.
Could you explain more what you mean by timing code? You mean stick in traces that ... what would I trace - the entry and exit times in different functions?
|
|
|
|
|
I think I may have a clue what's causing this...
I'm developing the program with VS2008 on the Windows 7 machine, but I'm maintaining compatibility with VC++6 on an XP machine because I want to compile the release version there. This is a commercial program for home users, and my customers will mostly be running XP. I don't want to statically compile MFC, and I don't want to make them go get updated DLLs.
On the XP machine, there is no delay in the file open dialog. It's just on the Windows 7 machine. I think this is because the common file dialog has been superceded on Vista and later:
http://msdn.microsoft.com/en-us/library/ms646927(VS.85).aspx[^]
I'll try switching to GetOpenFileName. If that's faster on Windows 7, then maybe I can use precompiler directives to use GetOpenFileName on Vista or later.
|
|
|
|
|
could your problem be related to this[^] ?
|
|
|
|
|
Oh wow. I think this may be it. I did speed it up by getting rid of the folder list, but it's still not as fast as I'd think it should be.
Thanks for this!
|
|
|
|
|
Duhhhhhh... The problem wasn't my code at all. It was a setting on my Windows 7 system. I was displaying the folder list on the left for File Open dialogs. File Open was taking a long time in all my programs - (Word, etc). I changed this, and now it's speedy.
I did try switching from CFileDialog to GetOpenFileName, but it made no difference.
|
|
|
|
|
hi: [posted elsewhere in forum, as I wasn't sure of best place]
I want to turn a Firefox Add-On I'm having developed [almost done] into a similar IE Extension; can you help with that? If so, please e-mail me.
pls let me know,
Marshall
|
|
|
|
|
Take a look at XPCOM[^].
The UI is created using XML and javascript.
|
|
|
|
|
He wants to create an IE extension doesn't he? XPCOM won't be much help there.
Steve
|
|
|
|
|
Damn!!! Misread it again.
I guess my answer should have been look at the IHTMLDocument2[^] interface.
|
|
|
|
|
That's a good place to start. You'll have a good few interfaces under your belt before you're up to making a plug-in of any substance however.
Steve
|
|
|
|
|
Is it possible to instanciate a COM object in C? I have tried googling this but to no avail.
The COM is created with C# and exposed. I can access the COM objects via C++ and VB6. For both C++ and VB6, I am using the tlb.
Thanks in advance.
-- Modified Thursday, April 22, 2010 4:29 PM
|
|
|
|
|
Try searching for articles on Code Project, with the search term "plain", C as the langauge, and COM as the technology. There is atleast one series of articles here on the subject, and you will be better off as using COM in C is complicated (but given that there are articles about it, doing so is possible).
|
|
|
|
|
Take a look at this excellent tutorial: COM in plain C[^].
It's time for a new signature.
|
|
|
|
|
Hello,
I´ve tried running at the same time two instances of the program below.
I pass the running time in seconds as a command-line parameter.
I pass different values to the two instances, 7 for one and 9 for the other.
int iTest=0;
int _tmain(int argc, _TCHAR* argv[])
{
printf("iTest: %d \n", iTest); // prints 0
printf("&iTest: %p \n", &iTest);
// This prints "00417178" for both instances !!
iTest = atoi((char *) argv[1]);
printf("iTest: %d \n", iTest);
Sleep(iTest * 1000);
printf("iTest: %d \n", iTest);
// Though the pointer &iTest is the same, each instance
// prints its own value !!
Sleep(5000);
return 0;
}
Two questions:
1) Why the pointer is the same but the values are different ?
I imagine that this value refers to a relative location, is this the point ?
2) In this case, I need to know: is it possible to get the absolute address of the variable in RAM ?
My need is to assure we are not having problems using the same spaces in memory in some variables we are creating.
Thanks,
Emerson - from S.Paulo, Brazil
|
|
|
|
|
It would seem that like most modern operating systems, the one you are using makes use of paging; therefore all addresses are fake. Therefore it can load them to diffrent real addresses, and tell the program it is at the address it was meant to run at (all programs are compiled to run at a specific base address).
|
|
|
|
|
Gwenio,
You answered my question 1, thank you.
But I still need to know - is there some routine from WinAPI that I can use to get the real / physical / absolute address ?
The fact is I´m using a module from another person and I suspect he´s sharing some variable among different instances. I must be sure if it´s happening or not.
|
|
|
|
|
chapultec wrote: But I still need to know - is there some routine from WinAPI that I can use to get the real / physical / absolute address ?
The fact is I´m using a module from another person and I suspect he´s sharing some variable among different instances.
WinAPI allow developers to share memory between applications without giving them knowledge of the physical address of the shared buffer, see [^].
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
First some problems with your code.
chapultec wrote: iTest = atoi((char *) argv[1]);
This is wrong. The type of the arguments is _TCHAR* argv[] so to assume the strings contained in the array are char*s is wrong. It should be something like this:
iTest = _ttoi(argv[1])
In general casting something into something it isn't (when the program is compiled as Unicode) doesn't transform it, it just tells the compiler to plough on and assume it is.
chapultec wrote: // Though the pointer &iTest is the same, each instance
// prints its own value !!
Each process has its own memory space, even two instances of the same process. To get the behaviour you seem to be expecting you'd have to use shared memory. Address spaces are visualised by the OS (with hardware support) and an address in a process is not the physical address of the memory. The only place you'd use physical addresses is in device drivers, and even then only in certain circumstances (like telling some piece of hardware to perform a DMA operation).
Steve
|
|
|
|
|
Steve,
You´re right on your comment about this casting, but this statement may not be wrong (when one knows what he´s doing ...) In my project properties - General - Character set - I changed character set to "Use Multi-Byte Character Set". The option "Not Set" would get the same result. Right ?
In fact I don´t need to use shared memory, but I need to know if the guys who developed the module I´m using used some kind of shared memory or not. That´s why I think I need some kind of routine to catch the physical addresses of some variables. I don´t know if there´s some way to get it.
Thanks.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
