|
I have create an application that has been grow quite quickly in the months running up to its release.
After the app was delivered to our main customers that there was a problem with the software when in was running under Windows 95.
The problem is based around failing to load icons and cursors from the resources.
I have been using the standard LoadIcon etc, but under Win95 the LoadIcon is returning NULL.
The problem may be larger than that as I have noticed that the Icon that sits at the top left of the app window in not the one specified but the default one (a grey box).
Does anybody have any idea what the problem could be.
Please help it's driving me mad.
|
|
|
|
|
I have a similar (but different) problem with animated cursors in the app's resources. Strangely, when I build with Static MFC Libs my call to LoadIcon returns NULL, while it works perfectly with MFC DLLs. This happens both in Debug and Release builds.
I tried every method to load an icon from the resources:
HCURSOR hAniCur = ::LoadCursor(AfxFindResourceHandle(MAKEINTRESOURCE(IDR_HOURGLASS),
RT_ANICURSOR), MAKEINTRESOURCE(IDR_HOURGLASS));
HCURSOR hAniCur = (HCURSOR)LoadImage(NULL, GetModuleHandle(NULL),
MAKEINTRESOURCE(IDR_HOURGLASS), IMAGE_CURSOR, 0, 0, LR_DEFAULTCOLOR);
HRSRC hResInfo = FindResource(NULL, MAKEINTRESOURCE(IDR_HOURGLASS), _T("ANICUR"));
DWORD dwResSize = SizeofResource(NULL, hResInfo);
HGLOBAL hRes = LoadResource(NULL, hResInfo);
PBYTE pResData = (PBYTE)LockResource(hRes);
HCURSOR hAniCur = CreateIconFromResource(pResData, dwResSize, FALSE, 0x00030000);
None of these methods works when linking with static libraries. I found a work-around some time ago, that can seem absurd, but really works on Win2000 and Win95, but not on WinME (and possibly others):
HRSRC hResInfo = FindResource(NULL, MAKEINTRESOURCE(IDR_HOURGLASS), _T("ANICUR"));
DWORD dwResSize = SizeofResource(NULL, hResInfo);
HGLOBAL hRes = LoadResource(NULL, hResInfo);
PBYTE pResData = (PBYTE)LockResource(hRes);
PBYTE pResCopy = new BYTE[dwResSize];
MoveMemory(pResCopy, pResData, dwResSize);
HCURSOR hAniCur = CreateIconFromResource(pResData, dwResSize, FALSE, 0x00030000);
That is copying the just loaded icon makes the system happy. 
I finally gave up when I tried this on ME...
But I suspect a bug in the resource compiler, because when I remove *all* the standard MFC resources automatically included in the app's resource script, everything is fine even with static libraries.
I also tried to extract my app's resources with other tools, to see if they were ok, I even compared the extracted resources with those of my dinamically linked app, but they were identical.
What to say? I even thought to download debug symbols for my system DLLs, to debug the call to LoadCursor and the others... but I have no will to do it.
All my comprehension,
Paolo.
|
|
|
|
|
HI ALL 
How I can play mp3 files from my program
any one can tell me how I can play mp3 files from my
program (by visual c++6) or tell me about web sites about mp3 files
THANK YOU
AHMAD ALWASHALI
|
|
|
|
|
Hi
go to the site www.xaudio.com
You'll find a SDK ( free !!!!!) to build in MP3 support in your apps
HTH
Thierry
EMail: Thierry.Marneffe@swing.be
|
|
|
|
|
Hi
go to the site www.xaudio.com
You'll find a SDK ( free !!!!!) to build in MP3 support in your apps
HTH
Thierry
EMail: Thierry.Marneffe@swing.be
|
|
|
|
|
There is a project at CodeProject that demonstrates skinnalbe apps by providing full source for an mp3 player. I have successfully removed the player classes and played MP3s in my own code.
XAudio is free, but it has a license agreement which basically states that they are free to decide one day that they want money for it, so I'd recommend not using it. I'd prefer to know up front if something is going to cost me, and how much. Otherwise, who knows what could happen down the track ? In that vein, fmod is a sound library that appears quite powerful, is free for use in non profit code, and gives you up front prices if you're going to use it in commercial code.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I recently noticed that when one of my work mates looked at their call stack debug window they hard say 30 lines of call stack info. However when I run the same project and view the call stack I only seem to get 3 lines of call stack info. Anyone know why please? 
|
|
|
|
|
It may be that you haven't got the symbol tables they have. The MS Visual Studio Tools program menu has a Windows NT Symbols Setup, which loads symbol tables for the core system DLLs - VC attempts to find these when it loads, and if it does, it can show more info when debugging.
I have an NT box, and the intial DLL load typically looks like this in the output window:
Loaded symbols for 'C:\WINNT\System32\ntdll.dll'
Loaded symbols for 'C:\WINNT\system32\KERNEL32.DLL'
Loaded symbols for 'C:\WINNT\system32\USER32.DLL'
Loaded symbols for 'C:\WINNT\system32\GDI32.DLL'
Loaded symbols for 'C:\WINNT\system32\ADVAPI32.DLL'
Loaded symbols for 'C:\WINNT\system32\RPCRT4.DLL'
Loaded symbols for 'C:\WINNT\system32\COMDLG32.DLL'
Loaded symbols for 'C:\WINNT\system32\SHELL32.DLL'
Loaded 'C:\WINNT\system32\COMCTL32.DLL', no matching symbolic information found.
Loaded 'C:\WINNT\system32\WINSPOOL.DRV', no matching symbolic information found.
In the call stack, I can see calls inside USER32, say, if I break in a messagebox loop:
USER32! ZwUserWaitMessage@0 + 11 bytes
USER32! DialogBox2@16 + 195 bytes
USER32! InternalDialogBox@28 + 121 bytes
USER32! SoftModalMessageBox@4 + 1579 bytes
USER32! MessageBoxWorker@4 + 357 bytes
USER32! MessageBoxExW@20 + 74 bytes
USER32! MessageBoxExA@20 + 100 bytes
USER32! MessageBoxA@16 + 22 bytes
The USER32! fn names are typical of what you get (no, for some reason, MS doesn't give us the code in a .pdb). If you're debugging, you still land in assembly, but you'll at least have names that can tell you where you are in assembly.
My theory here is that having the symbol info for the DLLs may help keep VC from cutting off the stack trace when it goes off into a system DLL, and thus allows you to see more.
|
|
|
|
|
I have a problem with DoVerb(). Instead of starting the OLE inplace activation so
that Excel comes up in the document being edited it returns an exception with error
code 0x80040003. This error code is not documented. I've found a knowledge base
article Q187920 that deals with Word97/Word95 incompatibilities which describes
error code 0x80040008. The fix for 0x80040008 doesn't work for 0x80040003.
I have three Excel documents embedded in the master document. One of the
documents works, the other two fail. They are all activated using the same code.
Does anyone have any ideas? I'm wondering if it could be caused by a corrupt Excel
document?
Cheers
Stephen Kellett
|
|
|
|
|
Answering my own question - well sort of. I now know what 0x80040003 means.
I found it in winerror.h - whcih is weird since the Error Lookup tool didn't
recognise the error code.
#define OLE_E_ADVISENOTSUPPORTED _HRESULT_TYPEDEF_(0x800040003L)
I can guess what this means, but if anyone has any advice, please do chip in.
Stephen Kellett
|
|
|
|
|
No sooner than I post this and add some extended error checking to validate
the OLE error codes, the function concerned changes its mind(!) and starts returning
STG_E_FILENOTFOUND.
Aaargh!
Stephen Kellett.
|
|
|
|
|
I have a program which has two views , but when I use the click and hold method, the highlights all the text when it scrolls up which does not look very good.(It doesn't scroll
synchronously in two views)
|
|
|
|
|
What is a sure fire way to switch to a cursor from the application's resources, within a limited area area of a view.
eg. Visual Studio does when editing an Icon, the 'pencil' cursor is active only while over the grid area.
Happy programming!!
|
|
|
|
|
In OnSetCursor, set the cursor if the mousepos is within the desired rect.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
I've got a problem. Our software processes some messages in a CPropertySheet derived main window class. When a user presses "ALT" key, the system menu is activated, same thing when user click on the top left window icon, the system menu drops down.
At this stage, when menu is active/down, the window doesn't process any incoming messages. I have written a separate thread that sends heartbeats to check if this state happens and now want to do somthing to de-activate the menu automatically wthout user intervention.
How?
I know that if I click somewhere in the window with the mouse, it de-activates the menu and messages gets processed again.
(Assume this software is run 24 hours a day and operator forgets to check it. By accident an operator press ALT and leaves. Now I want to detect this and fix the state to normal)
|
|
|
|
|
IMHO, stuff that needs to be running 24h a day shouldn't be in a UI thread at all. (It probably shouldn't even be in a process that has a UI thread, but in a service.) So put that stuff in a background thread and leave the UI thread to do UI processing only.
If you can't because the messages you need to process are real windows messages (and you can't change that), process them with a different, hidden window -- which you could put in a different UI thread, though I'm not sure that's necessary.
If you take the approach that you want to detect a stalled situation and terminate it, you have to make sure you identify all possible stall situations ahead of time. You've identified one already, and even if there aren't any others now, you or someone else might add one in the future.
By using a different thread and/or window, you're more likely to be able to handle all possible stall situations without failing to process the incoming messages. The UI will get out of sync with data perhaps, but the messages will still be processed.
|
|
|
|
|
You are right and I agree. However, the code is 6 years old and very complex (read bad). I was just hoping someone had a solution so I won't have to re-write all this code, also risking introducing bugs.
Oh, well, off we go...
|
|
|
|
|
I've got a problem. Our software processes some messages in a CPropertySheet derived main window class. When a user presses "ALT" key, the system menu is activated, same thing when user click on the top left window icon, the system menu drops down.
At this stage, when menu is active/down, the window doesn't process any incoming messages. I have written a separate thread that sends heartbeats to check if this state happens and now want to do somthing to de-activate the menu automatically wthout user intervention.
How?
I know that if I click somewhere in the window with the mouse, it de-activates the menu and messages gets processed again.
(Assume this software is run 24 hours a day and operator forgets to check it. By accident an operator press ALT and leaves. Now I want to detect this and fix the state to normal)
|
|
|
|
|
//
// This is, what I have actually written into my dialog's OnPaint()-function:
//
CClientDC dc(this);
CPen WhitePen;
CPen BlackPen;
CBrush BlackBrush;
WhitePen.CreatePen(PS_SOLID, 1, RGB(255,255,255));
BlackPen.CreatePen(PS_SOLID, 1, RGB(0,0,0));
BlackBrush.CreateSolidBrush(RGB(0,0,0));
CPen* pOriginalPen = dc.SelectObject(&BlackPen);
dc.Rectangle(24, 10, 80, 30);
dc.SelectObject(&BlackBrush);
dc.Rectangle(24, 10, 80, 30);
//
// Instead of the last two lines I've also tried it with:
//
dc.FillSolidRectangle(24, 10, 80, 30 RGB(0,0,0));
//
// How can I get rid of this flickering of the black rectangle in my dialog???
//
//
// Thanks in adv.
//
//
// Manfred
//
---
Programming is knowing...
|
|
|
|
|
override the dialog's OnEraseBackground (use classWizard). just return TRUE.
this will prevent the dialog's background color from being drawn
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
A few problems with your code:
First, you should be using CPaintDC in an OnPaint message. This is done automatically by the framework.
Second, You are creating pens and brushes, then selecting them into the DC, but not deselecting them which means that when the CPen is destroyed, it will not delete the pen you created (because it's selected in the DC) and will cause a resource leak.
|
|
|
|
|
To your first:
Why should I use CPaintDC instead of CClientCD ?
I'm having a dialog-based application and only want to paint a Piano-keyboard onto
the screen. This I will do once when entering the Dialog. At runtime I will change the
colors of single keys so no need for redrawing the whole keyboard - only single keys...
To your second:
I guess with 'deselecting' you mean 'deleting' my pens and brushes. Because deselecting
happens everytime I select a new Object with the SelectObject() function.
So do I get it right now ???
1 - Every DC has at least one original PEN, BRUSH, FONT, BITMAP and RGN.
2 - When creating a new e.g. PEN/BRUSH I have to store the original PEN/BRUSH with
CPen* pOriginalPen = dc.SelectObject(&NewPen);
CBrush* pOriginalBrush = dc.SelectObject(&NewBrush);
3 - and give it back to the DC at the end of the function.
dc.SelectObject(pOriginalPen);
dc.SelectObject(pOriginalBrush);
4 - Every pen, region, font, bitmap or brush created with e.g.
BlackPen.CreatePen(PS_SOLID, 1, RGB(0, 0, 0));
WhitePen.CreatePen(PS_SOLID, 1, RGB(255, 255, 255));
BlackBrush.CreateSolidBrush(RGB(0, 0, 0);
WhiteBrush.CreateSolidBrush(RGB(255, 255, 255);
5 - must explicitely be deleted with
(respectively AFTER having given my OriginalObjects back to the DC)
BlackPen.DeleteObject();
WhitePen.DeleteObject();
BlackBrush.DeleteObject();
WhiteBrush.DeleteObject();
6 - This means the objects are not deleted automatically at the end of the function.
I wonder why this DC related things are relatively difficult in comparison with other
parts of the MFC. I went through all the DC-related SDK and MSDN stuff and through
several books but this is realy not explained rather clearly in any place.
Hope that someone can get me out of this only-one part I do not realy get in my brain.
Thanks
Manfred
---
Programming is knowing... (should be  )
|
|
|
|
|
1/ You should use CPaintDC because CCLientDC is for getting a DC outside CPaintDC. I know you should never call CPaintDC outside OnPaint, but I admit you'll have to look elsewhere for a definitive answer as to why the reverse is true.
2/ Correct. Also true for bitmaps, but if you only select one bitmap into a DC, you'll never notice.
3/ Also correct.
4&5/ No. They are classes and have destructors. The CDC destructor cannot destory a pen it does not have, but if the DC is deleted in it's originla state, the destructors will do the rest.
6/ The GDI stuff is a thin wrapper on Win32 functions, and so it has not changed much. Although try writing this stuff in Win32 where you DO have to delete everything and it gets a bit harder.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
You must use CPaintDC in OnPaint because CPaintDC calls BeginPaint() and EndPaint() to validate the window regions when a WM_PAINT message is sent.
Look up CPaintDC and read the documentation.
When you select a pen or brush into the DC but do not unselect it (by selecting the original resource), then when the CPen or CBrush goes out of scope, the destructor attempts to delete the brush or pen, but cannot because it's selected in the DC. That means the delete fails and the resource is never deleted.
You don't have to explicitly delete the brushes or pens, since this is done automatically by the destructor of the CPen or CBrush object, so long as the brush or pen is not currently selected in a DC.
|
|
|
|
|
The advice you were given re: leaks is spot on, but to stop flickering, you need to double buffer. This means create a new bitmap and DC, draw into it and then copy the whole lot onto your dialog in one Blt at the end. Also, don't call CPaintDC until you're about to do the Blt and you won't need to undermine OnEraseBackground, which can have some nasty side effects. What will happen is this:
CDC myDC;
// Create DC, select bitmap and draw what you want on your dialog
CPaintDC dc(this);
// Background has been erased if necessary
// Now BitBlt from your other DC, so that the effect is immediate and you get no flicker
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
