|
 Hello,
I wrote a program and compiled it with Visual C++ on a WinXP computer. This program runs on a WinXP machine without problems. But when I put it on a Win98 machine it shows a strange behaviour. When I start the program everything but the program itselfs on the desktop becomes black. It seems that windows only refresh the active window. My english is not so good, but I hope someone can understand my problem description.
Kay
|
|
|
|
|
Does your program use any controls or DLLs that are either missing or outdated on the Windows 98 machine?
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
It is only a very small program. My program uses only a CListCtrl and no additional DLLs. Could be the problem cause of wrong compiler setting?
|
|
|
|
|
Steve S wrote:
Perhaps the original question meant "I want to switch views at run-time"
Well, quite! I suppose, since it is not explicitly stated what the person wants to do exactly, it is up for interpretation.
Ant.
I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain)
|
|
|
|
|
What is the equivalent to the C# #region/#endregion in VC++.Net? Or is there any?
|
|
|
|
|
Mark Nischalke wrote:
#region/#endregion
what are these ??????? 
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
There isn't any.
--
Joel Lucsy
|
|
|
|
|
1. I cannot, in either CBuilder or CV++ create a DLL which loads with LoadLibrary. What is wrong?
The two error codes i get is: 7f (function not found) and 6 (handle is invalid)
The errorcodes are not documented and I just CAN'T understand how i should fix the problems. I have created about ten different DLL:s, with just a DllMain, and still i have the same problems. Depends, and PEExplorer shows correct exports, and I have manually read the PE-header. Although I cannot find anything wrong with the DLL.
Quite urgent..... 
|
|
|
|
|
Dear experts,
Please show me how to redraw the background of static control (Group box) when its parent window has been set WS_CLIPCHILDREN style.
Best regards.
|
|
|
|
|
You would draw the static control like any other I would imagine.
If I remember correctly WS_CLIPCHILDREN prevents the parent window from painting anything underneath any child windows, which prevents flicker with any controls.
It's frustrating being a genius and living the life of a moron!!!
|
|
|
|
|
Thanks for your response,
When WS_CLIPCHILDREN is used, children windows have to do their painting themselves. Unfortunately, static controls, group box controls cannot draw their background. My temporary solution is setting the WS_EX_TRANSPARENT to these kinds of control (e.g. group box). Of course, they will flick, but the others can enjoy flicker-free.
So, as what I said, I still used WS_CLIPCHILDREN to prevent flicker except static, group box controls.
I'm still waiting for a complete solution.
Thanks again.
|
|
|
|
|
do you have idea to expand all tree items of a html help on context window programmatically - by C++ or settings of the help?
thx
includeh10
|
|
|
|
|
Hello!
I'll preface this by saying I'm a complete novice with C++; the bulk of my programming has been in VB 5/6 and VB .Net, but I have an issue with an SDK that is designed for C++, and I need it to work with VB.Net.
My issue is this; two of the functions in the DLL supplied with the SDK use a structure that has a datatype in it that is a Union (unions, of course, aren't that well supported in VB .Net). So, I decided the best route was to create my own C++ DLL that would handle the two functions that need to use this Union datatype, meaning all I would need to do is supply an input parameter (an integer in my case) and recieve and output parameter back (another integer). Calling the functions from VB .Net is easy, but that's not my problem.
I've written the C++ DLL basically by copying and pasting from the C++ header files supplied with the SDK, as that made the most sense given my lack of C++ knowledge. I have a header file that has all of the datatype definitions, an additional header file for the structure and union definitions, and then a ".cpp" file for the actual function call:
void ReturnTheDataINeed(cdHandle hEnum, cdHandle &hnd)<br />
{<br />
HINSTANCE hLib;<br />
<br />
cdError err;<br />
cdHEnum hEnumDevice;<br />
cdSourceInfo* pSourceInfo;<br />
cdSourceInfo SSrcInfo;<br />
cdHEnum hNext;<br />
<br />
cdEnumDeviceNext NextDevice;<br />
<br />
hLib = LoadLibrary("CDSDK.dll");<br />
<br />
NextDevice = (cdEnumDeviceNext)GetProcAddress(hLib,"cdEnumDeviceNext");<br />
<br />
pSourceInfo= new cdSourceInfo;<br />
err = NextDevice(hEnum, pSourceInfo);<br />
<br />
FreeLibrary(hLib);<br />
<br />
hnd = hEnumDevice;<br />
};
These are the type definitions (also copied from the SDK)...
<br />
typedef unsigned long cdError;<br />
typedef unsigned long cdHEnum;<br />
- cdSourceInfo is a structure that holds data about the device, and I can supply the definition if it will help.
cdEnumDeviceNext is a function pointer as follows...this is copied out of the SDK's header files under 'function pointers'.
<br />
typedef cdError cdSTDCALL cdEnumDeviceNext(<br />
cdHEnum hEnum, <br />
cdSourceInfo* pSourceInfo<br />
);<br />
cdSTDCALL is defined as this:
<br />
#define cdSTDCALL __stdcall<br />
And finally, I have the second function (cdOpenSource) commented out because...this dll does not build. When I attempt to build it, this line:
<br />
NextDevice = (cdEnumDeviceNext)GetProcAddress(hLib,"cdEnumDeviceNext");<br />
...throws the error "C2066: cast to function type is illegal" and what I presume is just a follow on, "C2659: '=': overloaded function as left operand".
I found the GetProcAddress and LoadLibrary calls off of the web as the defacto standard for getting functions out of dlls, but I've yet to find an explanation for my error. My current assumption is that maybe my function pointer is wrong, but I'm not certain on that because again, I copied it from the supplied header files from the SDK.
Any help that could be offered would be most appreciated.
Thank you,
Daniel Gow
|
|
|
|
|
GetProcAddress return the pointer to function of the call you are trying to make and in your case it will be returning address to pointer of cdEnumDeviceNext. I don;t know about what was being done there but you should have a declaration of pointer to function of 'cdEnumDeviceNext' something as follows
<br />
typedef cdError (CALLBACK* LPFNcdEnumDeviceNext)(cdHEnum, pSourceInfo);<br />
and then you go like this..
<br />
hLib = LoadLibrary("CDSDK.dll");<br />
<br />
LPFNcdEnumDeviceNext NextDevice = NULL;<br />
NextDevice = (LPFNcdEnumDeviceNext)GetProcAddress(hLib,"cdEnumDeviceNext");<br />
<br />
pSourceInfo= new cdSourceInfo;<br />
err = NextDevice(hEnum, pSourceInfo);<br />
<br />
FreeLibrary(hLib);<br />
I hope you understand and that I have not made it more difficult for you...
|
|
|
|
|
Thanks for your reply! I'm sure I never would have figured that out on my own...and I understand it vaguely enough for it to make sense to me - which is enough. It works great too, builds properly and all that and I added a little bit of error handling (such as it is) to the mix.
One problem I'm having though is that my VB app can't find the function in the DLL. Is there a special way I need to declare the function so that it's what I'd call "Public" in a VB .Net sense, or visible beyond the scope of the inner workings of the DLL?
At the moment the function starts as...
<br />
cdError ReturnCamera(cdHandle hEnum, cdHandle &hnd)<br />
- cdError is just another unsigned long.
Thanks again!
|
|
|
|
|
Any function to be exported from a DLL should be preceeded by some declaraion that shows that this is an exported function. So you can try to declare the function as
<br />
extern "C" __declspec(dllexport) cdError __cdecl ReturnCamera(cdHandle hEnum, cdHandle &hnd)<br />
__declspec(dllexport) shows that this is a function that dll exports and all other define C type convention for export.
with the above declaration I have called this function from C# .NET so I think this should work with VB .NET
|
|
|
|
|
Thanks so much for your reply!
I unfortunately can't say that my DLL is working, but the problem I have now is one in relation to the SDK, not with C++ or the help you offered. The 'extern "C" __declspec..." line did the trick fine, and I'm starting to get the hang of this!
Thanks again.
|
|
|
|
|
Hi
Need help. How do i get all Files and Directories in a specified Directory 
MFG
RedDragon2k
Unix and C are the ultimate computer viruses.
|
|
|
|
|
|
Save yourself some trouble and look here[^] under the General section and file globbing.
It's frustrating being a genius and living the life of a moron!!!
|
|
|
|
|
The default of an SDI application is SW_SHOWDEFAULT = SW_NORMAL.
How and where can this be changed to SW_MAXIMIZE?
thanks
|
|
|
|
|
Are you wanting to make the frame initially maximized? If so, just change SW_SHOW to SW_MAXIMIZE in the app's InitInstance() method.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
I have a class called 'CWatchedWindow', and a vector container in my dialog class to hold pointers to CWatchedWindow objects.
I'm trying to use the find algorithm on the vector for a new object. The determining factor for one CWatchedWindow object to be equal to another is the string it holds, (m_strName). The operator== works in a simple if() statement, but it won't call any of the overloaded functions for operator== when I use the find algorithm using a pointer to an object of type CWatchedWindow. And I can't use it by de-referencing the pointer, because the template won't recognize it. Here's my class definition:
class CWatchedWindow
{
public:
unsigned long m_nSeconds;
CString m_strName;
COleDateTime m_lastTime;
CWatchedWindow()
{
m_lastTime = COleDateTime::GetCurrentTime();
m_nSeconds = 0;
}
bool operator== (const CWatchedWindow& sWord )
{
return m_strName.CompareNoCase(sWord.m_strName) == 0;
}
bool operator== (const CWatchedWindow sWord )
{
return m_strName.CompareNoCase(sWord.m_strName) == 0;
}
bool operator== (CWatchedWindow* pWord )
{
return m_strName.CompareNoCase(pWord->m_strName) == 0;
}
bool operator== (const CString& sWord )
{
return m_strName.CompareNoCase(sWord) == 0;
}
};
and here's the call to find:
CWatchedWindow win;
win.m_strName = m_strLastWindowCaption;
CWatchedWindow* pWin = &win;
vector<CWatchedWindow*>::iterator findIter;
findIter = find(vecWindows.begin(),vecWindows.end(),pWin);
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
|
The problem here is you're comparing pointers, and not the objects they point to.
Here's the code for find algorithm:
<br />
{
for (; _First != _Last; ++_First)<br />
if (*_First == _Val)<br />
break;<br />
return (_First);<br />
}<br />
*_First dereferences the iterator, which gives you a pointer to a CWatchedWindow. So basically, you're doing this:
<br />
int * x = 0;<br />
<br />
if (x == 10)<br />
<br />
whereas you want this:
<br />
int * x = 0;<br />
<br />
if (*x == 0)<br />
<br />
The way that I know to get around this problem is by using find_if() with a predicate.
<br />
<br />
class MatchName<br />
{<br />
MatchName(LPCTSTR lpszName) : m_strName(lpszName)<br />
{<br />
}<br />
bool operator()(CWatchedWindow* window)<br />
{<br />
return (window->m_strName.CompareNoCase(m_strName) == 0);<br />
}<br />
}<br />
<br />
<br />
iFind = find_if(blah.begin(), blah.end(), MatchName("Window Name"));<br />
<br />
if (iFind != blah.end())<br />
AfxMessageBox("Found it");<br />
<br />
The code for find_if is as follows:
<br />
<br />
for (; _First != _Last; ++_First)<br />
if (_Pred(*_First))<br />
break;<br />
return (_First);<br />
The _Pred(*_First) line triggers the function call operator defined in MatchName for each of the objects in the vector.
I think there is a way to avoid creating a class (ptr_fun? or something bizarre like that), but I'm only familar with the above method.
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Cool! I thought about the find_if(), but I thought I was doing something wrong, that I should've been able to do it with find(). I stopped using pointers yesterday when I got frustrated, and just used the objects themselves. Either way, the same amount of CWatchedWindow objects will be hanging around for the duration of the program, and I don't have to worry about memory leaks this way. Is there any reason you can see why I shouldn't use the objects themselves instead of pointers? This seems to be a cleaner solution, but I'm not sure. Your solution is great, but I'm thinking it's better not to use workarounds if I don't have to?
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
