|
Have a look at this article[^] at the section called "Worker threads and the GUI II: Don't touch the GUI".
|
|
|
|
|
It would be not possible
to manage any alarm events or even the mouse click events -
without the updating of a complex drawn picture
(for example, with motions, blinking, transformations, Direct2D interludes...) -
by a worker thread... But it is possible (with a worker thread) 
virtual void BeHappy() = 0;
|
|
|
|
|
I want to use the CHtmlEditView in my vc 6.0 project, it is a MFC project.
so i added the header file 'afxhtml.h' and then added the following line.
CHtmlEditView htmleditview_object;
then i compiled the project and its giving the error like
error C2501: 'CHtmlEditView' : missing storage-class or type specifiers.
what should i do?
How do i solve this problem?
sunnyram
|
|
|
|
|
I know this is an obvious (stupid?) question, but are you sure you put your #include in the correct source module?
It's time for a new signature.
|
|
|
|
|
I was wondering that, but decided not to ask...
Steve
|
|
|
|
|
Yes, i have put #include in correct source module and what is the new signature?
can you explain little more?
sunnyram
|
|
|
|
|
sunnyram wrote: what is the new signature?
can you explain little more?
That way you should explain 'sunnyram'.
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]
|
|
|
|
|
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).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
