|
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..
|
|
|
|
|
Hi Ryan,
I think you get 20 because, when you compile the exe, the compiler knows its implementation of CA, so it calls its functions. The compiler has no mean to distinguish between a CA object created in your exe and one created in the dll.
An object contains only data members and virtual tables, the member functions are just like any other global function, but they are passed this as the first parameter: this is how they can actually access object's data.
When you use a CA object constructed in the dll, you get its binary data but not its member functions.
And I think you may have unpredictable run-time errors if their internal data format is not the same.
I don't know how you can solve this
Cheers,
Paolo
|
|
|
|
|
a) If you want two implementations of the same interface, you need to use virtual functions. Make a base class that has your interface, and then derive two classes from it - one that returns 10, and one that returns 20.
Then objects of your class will have a virtual method table (pointer at the beginning of the object's data) that points to a list of function pointers, that's how you can get a different function to be called. The first responder had the right idea RE: returning a pointer to a pointer.
b) Just make sure that the EXE and the DLL both include the header file that defines the interface, and they will work with each other.
c) DLLs can be C++ specific, they don't -have- to be compatibile with Visual Basic or any other language.
|
|
|
|
|
For MFC programmers, an important distinction is whether a DLL is an MFC Extension DLL or not. It is certainly true that a regular DLL can be C++ specific to the extent of being incompatible with other languages such as Visual Basic, but what is important is that MFC classes can be shared between EXEs and DLLs only when the DLL is an MFC Extension DLL. See MFC "TN011: Using MFC as Part of a DLL" and "TN033: DLL Version of MFC".
|
|
|
|
|
Howdy Folks!
Is there a way to redirect my dialog to get its own system colors somewhere else in the registry? I know how to write the colors into the registry, but I want to know if there is a way to make my application only to look for the registry colors elsewhere.
I would also like to know how to change the color of the Menu in my MFC application, I have tried to add code to my OnDrawItem when its called by the Menu, but I don't know if I use the right commands (I'm no ACE at C++ so far, hehe, learning fast though)
Another "thingie", hmm... I have set my dialogs background with the SetDialogBkColor() but it seems like the (what do you call it, hmm... border, frame, nm) the outer edge of the window is still taking the colors from the system. How do I paint that area?
Then there's the problem with my controls. I have a Slider that still takes the system color in it's "slider-path" and on the "slider-knob" (or whatever you call these, hehe). Where can I set those colors?
Then theres my ComboBox wich has that little arrow, (you know, the one you klick on to bring down the ComboBox's menu) I want to set its color too =)
If you happen to know how I can "redirect-the-registry-thingie" there's no hurry for the rest of the answers, but I'd like to know the other ways to do it too =)
Thats all Folks, thanks for redin'!
/Fredrik
|
|
|
|
|
Before you go messing around with color in your dialog box, you should go to this web page:
http://www.iarchitect.com/mshame.htm
It talks about all of the evils of user-interface design.
Sure, you can setup your own registry keys for colors, but at that point, they are no longer considered "system" colors.
In order to paint the 3-d portions of your dialogs, you'll probably have to override the OnPaint() function and do *all* the drawing yourself.
As far as painting controls, the same thing applies, only you'll have to subclass the controls and override their OnPaint code too. Don't forget to make them owner-drawn in your dialogs too.
Are you sure all of this is worth the effort?
If you want to make your dialogs look more vibrant with less work, use Visual Basic...
|
|
|
|
|
Hi again!
Thanks for the info John, and the site you gave me was good. I do need to change the colors though, even though it's sort of against my will, hehe. How do I direct the registry so that I can make my application get its own colors (true that they wouldn't be "system" colors no more, like you said, good point). I want the colors of the other applications running to still use the real system colors, and only my application to use the "fake" or call them "virtual" system colors. =)
I would guess that this way would be the best since it would give me a better view of the colors than to override OnPaint code for all the controls.
Thanks again,
/Fredrik
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
