|
How to change the PropertySheet tab caption's color
|
|
|
|
|
So I've used the old _CrtDumpMemoryLeaks() and found my program has leaks. Now I want to use _crtSetBreakAlloc() to stop before these errors. However, during runtime none of the following expressions succesfully evaluate:
-> _crtBreakAlloc
-> {,,msvcr40d.dll}*__p__crtBreakAlloc()
-> {,,msvcrtd.dll}*__p__crtBreakAlloc()
and I've also tried setting my code configuration to Debug Multithreaded DLL, and Debug Single Threaded, Multithreaded DLL, all which produce the same result? I've also tried setting compile time _crtSetBreakAlloc(). Oh, and it is definetly the building in debug configuration.
Thanks in advance for any help...
Brendan Tregear
Scan Optics
32 Stirling Street
THEBARTON
SA 5031
|
|
|
|
|
I can't help much except to suggest that you state explicitly whether you are using MFC. Are you using VC 6?
|
|
|
|
|
Something I do on occasion (as per MSDN docs) is start the prog with F10, then during the initial break, bring up the watch window and type in _crtBreakAlloc. If its 'there' it should show as -1. I then manually enter the number of the allocation I'm trying to track down.
I should note that my exp with this has been with MFC, and CObject dumps. But this little test might serve to show you if the var is available.
|
|
|
|
|
Thanks for your help everyone but it still doesn't work. I've followed the directions exactly according to Knowledge Base Question ID: Q151585 "HOWTO: Use _crtBreakAlloc to Debug a Memory Allocation" without luck.
Looks like I'll have to get an off-the-shelf memory-leak detection package.
Thanks anyway 
Brendan Tregear
|
|
|
|
|
Spending a day at home (nursing a cold - sympathy welcome) so thought I'd play with this a little bit - using a single threaded console application - and may have 'half a solution'.
The problem seems to be one of declaration and linkage - the prototype for _crtBreakAlloc begins with _CRTIMP, which resolves to nothing if not building a multithreaded dll. (Maybe the key is to place this stuff in a DLL and link with it)
Anyway, I managed to redefine and assign _crtBreakAlloc thusly:
extern long _cdecl _crtBreakAlloc = 21;
which the linker complained about. Telling the linker to use the FORCE switch got past that, and the allocation did cause a debug break.
Not a very robust solution though. Maybe someone else can expand on this. Would be nice to know a straightforward way of linking with these methods.
|
|
|
|
|
Thanks Tim, it works. You've got my sympathy *and* gratitude
Regards
Brendan Tregear
Scan Optics
32 Stirling St
THEBARTON
SA 5031
|
|
|
|
|
Hi Everyone,
I have a question regarding generating random number. Is there a function that can generate random number between a range without having the random number repeat itself?
For example, let's say I have 100 records in a database. i want to randomly select a certain number of records upon user input and make it as a new table.
if i use rand() function, and mod the numbers by 100, i'll get the numbers between 1 and 100, which then i can use to set the position of the record to copy that row of data. but the numbers might repeat themself if i select a large amount of records out of the 100.
is there a way to check the random number generated to see if it has already been selected before?
If anyone knows, plmk. thanks
steve
|
|
|
|
|
Sure, just store each random number generated in a map or list.
#include
std::map<int, bool=""> gen;
int x = randomnumberfuncitonyouarecalling();
if (gen[x] == false)
{
// do your code
gen[x] = true;
}
else
{
// try again
}
|
|
|
|
|
Hi Steve,
A standard procedure for this problem is to generate a sequence 1..n and pemutate these numbers randomly (n log n times should do the job). This is efficient if you want to access a certain number of items mutliple times.
Wolfgang
|
|
|
|
|
How can I change extended style on startup or under the time dialog is active.
|
|
|
|
|
|
How do I create a DLL that there can only ever be one instance of it.
Details:
I need a server that is shared by many processes.
This server will be registering each process that loads it.
When the server is notified of deltas by an EXE that will start it, it will in turn broadcast to each registered process.
So, there can be only one data segment.
|
|
|
|
|
You're kind of throwing the baby out with the bathwater.
There is no reason you should have to require that a DLL is only loaded once. There are many ways share data between multiple instances of a module (such as DLL's). Shared data segments (check the linker options for this) and memory mapped files with page backing (essentially maps the same memory into the swap file and allows mutliple processes to read and write to it) for instance.
Further, you can accomplish this without sharing memory. This is precisely what out of process COM objects are designed to handle.
There are lots of solutions besides this (which is basically impossible in 32 bit anyways, since each DLL is mapped into each programs address space. )
|
|
|
|
|
Thanks for the feedback Erik,
Perhaps I mistated my End-Goal.
We need a dll that no matter how many clients load it, they all get exactly the same one from the perspective of Connection Points.
What we have is an EXE that will load the dll initially.
The Listener.dll is an AddIn for Visual Source Safe to trap SourceSafe events.
Once the EXE has loaded the Listener.dll, then it will load ssapi.dll (sourcesafe).
ssapi.dll will load our Listener.dll again.
Then many clients will register with the listener to be notified of changes to the source safe database.
Only the instance started by SourceSafe is the one that will recieve the events from sourcesafe.
Am I goofy or what? I have not successfully built a singleton dll. singleton exe, yes. ?????????????
Isn't singleton the solution?
|
|
|
|
|
No. You simply cannot have what you want under Win32. The reason is simple. A DLL is loaded into each processes address space. Without that, a program couldn't access the DLL since it wouldn't exist in it's virtual space.
Under Win16, there was only one global address space, so DLL's were only loaded once. But in Win32, each program has it's own and DLL's can be relocated anywhere in the space if some code already exists at the preferred loading address.
That's why I suggested shared memory segments to share the common data.
|
|
|
|
|
Ok, I'm aware that it lacks in details, but that's what I have so far:
Someone here implemeted a skin mechanism for an application.
He uses a script and compiles it into a resource list.
I'm pretty sure he used bitmap streching for resizing.
The problem is this:
Resizible windows that he defines as Dialogs leave ugly background color marks when resizing them. This only happens on Win9x (Inferior GDI performance?). Windows that are defined as CWnd and not CDialog do not leave the color traces.
Any leads on where to start solving the color traces of the dialogs? How is Dialog resizing different from windows resizing?
Thank you, Any help would be great.
Ori
|
|
|
|
|
I need to add a script after a request of some asp files.
My solution: In the method OnURLMap if the physicalpath is filename.asp it creates a temporary file at the same directory called ~filename.asp and it changes physicalpath to this new file.
Why doens't it works?
Client's browser receive Errors 500 and 404 file not found.
Obs: New ~filename.asp is created and can be accessed by it's url.
|
|
|
|
|
Hey,
Does anyone know about a quality resource that would show me how to store and retrieve BLOBs (specifically, an image) to and from a database? (In MS-SQL Server 7/2000, using ODBC).
Thanks!
Oz
|
|
|
|
|
HI,
I want to pass class* as a parameter to DLL..
Without using MFC extension dll...
I mean as a regular dll..
I think when I correctly pass the address information of
Class*, I could call the method of it..
Is it difficult to understand??
See Next codes:
In exe :
1. declare Class CA (no inheritance..)
2. define all the methods of Class CA..
3. in some handler code,
CA* inexe = NULL;
Set(inexe);
inexe->aa();
inexe->bb();
In Dll :
1. declare and define export func Set() as follows:
void Set(CA* indll)
{
CA SI; //SI is instance of CA in DLL
indll = &SI;
}
2. then I can copy the address of CA instance in DLL..Right?
so now inexe has address of CA instance in DLL..
Is it correct??
One more thing that makes life horrible..
I'll declare and define of CA in exe that has different
implementation of CA's methods...
I mean, in dll aa() returns 10 but in exe aa() return 20...
Then I'll call methods of CA in dll...
But in reallity it won't work...
In exe, when I call the Set() with appropriate CA*,
the result of inexe()-> returns 20 not 10...why??
I think when using the address, I could access the
CA implementation in DLL..
But It just wouldn't work..
If anybody has a interest in this send me a mail...
Then I'll send you immedialtely complete sample DSW...
and other DSP and cpp..h...lib...exe....dll...OK??
So thanks for reading ....
Regardz
-Ryan
|
|
|
|
|
There are a few things that you'd need to change to make it work the way that you intended it to work.
First of all, you need to change the Set function to take in a pointer to a pointer.
Secondly, in your set function you are creating a CA object on the stack (which will get destroyed as soon as the function returns, even though you may have copied the correct address - which doesn't happen anyway.
Try this...
In DLL:
Set(CA** ppCAInDll)
{
CA * pA = new CA;
*ppCAInDll = pA;
}
In EXE:
CA* inexe = NULL;
Set(&inexe);
inexe->aa();
inexe->bb();
Make sure you delete the object pointed to by inexe, since it's been new'ed in the dll.
|
|
|
|
|
Hi, really thanks for your response....
Unfortunately, it just wouldn't work..
I think the same idea like you...I have to pass the
address of class's intance...I mean I should pass the
address of pointer to class's instance in DLL..
Anyway, the result of aa() is that of the implementation
in exe..not in DLL..
As far as I know about the class memory allocation modeling,
the pointer of class should point the instance's top..
In this case, (no member variable, 4 member functions)
it should point the constructor(first method)'s address..
So I think that if I could point out the proper address
of class, I can point the proper binary implementation...
But, as a result....I was wrong..
I want to find this out what the hell is going on in dll..
And about the class memory allocation...
If you have some interest about this..Let's dig it out!!
Give me your e-mail...I'll send you the whole codes I have..
If not...Thank you very much for suggestion..
And later I'll let you know the result of my study..
Regardz
-Ryan
-p.s The former responser's idea is wonderful..
I theaded also his idea..
Checking it out will be helpful too...
|
|
|
|
|
I don't really have a lot of experience in this field, but I think using a second set of dll's for the different classes (one for each class you want to use) should do the job (passing the current class-dll-name to your dll, which dynamically loads it). Exporting classes form dll's is documented in some postings on codeguru and codeproject).
Wolfgang
|
|
|
|
|
I think that there is a fundamental concept that must be understood. A regular dll (a dll that is not a MFC extension dll) can be called by programs compiled by any compiler capable of calling DLLs. That is, your dll is compatible with Visual Basic and many other development facilities. Most of them do not know what a C++ class is, so it is unlikely (impossible?) for you to be able to have a class as a parameter.
I that a couple of possibilities are:
(1) make an MFC extension dll that can be called by your MFC programs and a second dll that is a regular dll that calls the first dll and that can be called by non-MFC programs
(2) create an (ActiveX) Automation interface, which (I think) can be implemented as either a dll or an exe.
A third possibility might be that you write an MFC extension dll and a separate exe that provides an Automation interface and that calls the extension dll.
|
|
|
|
|
Hi, Thanks for your response..
A regular dll..and not MFC extension dll..
As I found a minute ago in MSDN,
the regular dll has 3 types..
1. Non-MFC DLLs
2. Regular DLLs statically linked to MFC
3. Regular DLLs dynamically linked to MFC
I used #3 type...And what you point out is #1 type..
Hm....
Well, you are right in your point..Sorry for I didn't state
the exact information about situation...
In #3 type, I can use classes in DLL and can not export the
class and all other members of it..Am I correct??
But I can't convince that I can export class* as a parameter
Anyone know about this....??
And about your suggestion on possibilities:
(1)DLL in DLL...
I wonder if an exe can't access the dll's exports, neither
it is with regular dll...
And I have no compile error and link error with #3 type,
I would not think about this...
(2) Use Automation Interface....
Using COM...well I think I could make this dll as COM server
But what is with the Automation??..Need your teaching...
And my target is polymorphism of method's implementaion..
I'll separate implementation of class's method in exe and
in dll so that I can use proper method of it...
I know this is not the purpose of dll and c++..
If I need polymorpism, I can use virtual keyword..
But this is not good for reuse, as you can read in Essentil COM #1, for the real reuse of codes..
The source level reuse of legacy code is not effective..
And I'm tired to work on registrys....Huh...
So for simple functionality I'll use this way rather than COM and ATL..
This is some copycat of COM..
Until the unveil of C# and .NET, I don't want to implement
COM server..I'll just use components the others have done..
In .NET and CLR, COM is just a file...no registry needs..
Huh...
Anyway thanks for your response...
Regardz
-Ryan
-p.s Read the other thead of my question..
Mr. Jignesh made a good response...Check it out..
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
