|
Anyone know how to use data_seg() for sharing memory among a dll and an app? I have :
#pragma data_seg(".myseg")
int length = 0
#pragma data_seg()
in both my app header AND my dll? I change the variable in the dll but it does NOT affect the reference in the app  Is there something I am doing wrong? How do I set it up for sharing so that when I change the variable in one set out virtual memory, it automatically changes the reference in another?
Thanks to all.
|
|
|
|
|
Oh, I'm also using the #pragma comment(linker, "/SECTION:.myseg,RWS") statement in the header too so the linker can SUPPOSEDLY share the variable data memory.
Ta.
|
|
|
|
|
The shared attribute for a section only allows a DLL to share its own data when it is loaded multiple times for multiple processes. It doesn't allow an application to share data with the DLL.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ahhh, right, I guess every subsequent dll that loads would map that variable to the same place in memory. Is there anyway of doing the same thing with an exe and a dll so a variable has application-wide scope? I'm trying to develop an interface class that keeps track of a list and ensures memory is cleaned up at the appropriate times. Trouble is the exe or the dll will both want to use it and I don't want separate instances of the class cos there is common data. Could I use _declspec(dllimport) to import it from a dll into an exe? and then have all subsequent dll's import it from the first one? or should I have a dll that sets up a shared data_seg() for sharing between other dlls and just have the exe import it? Bah, I'm running round in circles over something that should be as easy as 123. Cheers though Ryan.
|
|
|
|
|
Biped wrote:
Is there anyway of doing the same thing with an exe and a dll so a variable has application-wide scope?
No
Biped wrote:
or should I have a dll that sets up a shared data_seg() for sharing between other dlls and just have the exe import it?
Is the DLL loaded by multiple programs such that it has to share data between them? Or is it only important between the EXE and the DLL? If it has to share data between multiple programs, then what you said there is the way to go. If only the one EXE and DLL need to share the data, then you're better off having a single instance of the class, and pass a pointer to the instance between your DLL and EXE.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Yeah its just between the exe and the dll, no other app should share that data. I'm thing the pointer to the instance is the best way to go about now after weeks of thought. The one thing that was holding me back was whether it would still be valid in the dll because the memory offset would be different wouldn't it? I have noticed someone suggest using COM but am unsure? Thanks for your help though Ryan, you've been very helpful.
|
|
|
|
|
Biped wrote:
The one thing that was holding me back was whether it would still be valid in the dll because the memory offset would be different wouldn't it?
No. The memory address would be the same. The DLL simply takes up space in the EXEs address space. Anything the EXE can read, the DLL reads from the same address.
Biped wrote:
I have noticed someone suggest using COM but am unsure?
You could use COM, as long as you make your object a singleton (one instance only).
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Yeah, the object is a singleton, and I'm thinking that I could use the COM practicality for other uses too. Trouble is I've never used COM before so I'll have to scout around for some info on it. I suppose it does make the most sense actually, since it is a structured way of programming an interface, which is pretty much what I want  . Now I know it has to have a pure virtual class that defines the interface which derives off IUnknown to track reference counting. How then do I utilise in my scheme of exe and dll? The dlls will be single instances of different dlls, would I just obtain a pointer from COM and pass it to each dll or what . Help Ryan
|
|
|
|
|
Sorry, COM is something I know almost nothing about. I've used it from a client, but I've never written a COM object, so I can't really help you there. If you've decided to write a COM object, post another more specific question, and someone else will help
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Haha, I've uncovered a hole in Ryan's knowledge base . Heheh, wow. Anyway, thanks for all your help with this problem, I appreciate it immensely. I'll write a COMponent module and post another big Q up when I get into trouble.
Thanks again.
Alan.
|
|
|
|
|
Dangleberry wrote:
Haha, I've uncovered a hole in Ryan's knowledge base . Heheh, wow.
 Gee, it's not that amazing 
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Perhaps not amazing, but surprising yes  , you do get around on codeproject a bit you slag 
|
|
|
|
|
Just to further clarify, I want one exe to share the data between it and x amount of dlls that need the class (not sure how many there may be at this stage). What would you recommend in this case? Cheers Ryan.
|
|
|
|
|
As long as it's the same DLL being loaded multiple times, I'd use a shared data segment that holds the data, and then pass the instance to the applications.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I'm thinking that I can finally eliminate data_seg() as a solution
|
|
|
|
|
I'm filling a CComboBoxEx with the names of truetype fonts; CComboBoxEx is convenient because it's easy to draw bitmaps (the truetype logo) for each item.
Problem : although CComboBoxEx is derived from CComboBox, it does not inherit all its methods & properties; for example to add strings, AddString won't work, you must (?) use InsertItem.
Result : the items are not sorted.
I will have to presort my strings in an array, before adding them in the combo, or is there a better way ?
|
|
|
|
|
I guess the thinking was that since CComboBoxEx would most likely be used for non-strings items, sorting was not needed.
JP GOBLET wrote:
I will have to presort my strings in an array, before adding them in the combo, or is there a better way ?
Put the names in a CArray, call qsort(), and then populate the combobox.
|
|
|
|
|
thanks - perhaps microsoft could one day make a control fully functionnal out of the box,
rather than forcing us to always search for fixes
|
|
|
|
|
But if they provided everything for you, how would you learn anything? By leaving bits and pieces out, you are forced to go out and explore.
|
|
|
|
|
oh, so thank you microsoft ...
my point of view is simple : i get paid for writing applications; searching algorithms to resolve the customer problems is already a lot of work and learning. Fixing interface parts is a waste of time, and not very profitable learning. Of course i could (or rather my boss could) buy a complete interface library, but that would be hard to justify, because the interface parts we get for 'free' in MFC are almost good enough ...
I don't want to be 'religious' about that. After all my salary is the same at the end of the month whatever if spend my time on, and i concede that customizing a control, and even making it work in a way in wasn't designed for, can be a lot of fun (if you can do it in a reasonable time !)
|
|
|
|
|
DavidCrow wrote:
Put the names in a CArray, call qsort(), and then populate the combobox.
Exactly the info I needed, thanks.
For the others people interested in this solution, there's an article in MSDN about Array and sorting:
Q216858 - HOWTO: Quick Sorting Using MFC CArray-Derived Classes
|
|
|
|
|
My beginning visual C++ book says that when you declare a CArray, and then call the SetSize() function, the global helper function ConstructElements() is called to allocate memory for the number of elements you want to store. The default version of ConstructElements() sets the contents of the allocated memory to zero and doesn't call a constructor for your object class, so you need to suppy your own version of ConstructElements() if that action isn't appropriate for your objects. That will be the case if data members of objects of your class are allocated dynamically, or if other initialization is required.
First of all, if my object class looked like this:
(sorry, the code tags are not preserving the indenting)
<br />
class A<br />
{<br />
public:<br />
A(int* p)<br />
{<br />
pint = new int;<br />
*pint = *p; <br />
}<br />
<br />
private:<br />
int* pint;<br />
};<br />
why do I even need to implement ConstructElements()? If I declared a C++ array like this:
<br />
A MyA_Array[10];<br />
I wouldn't have to do anything special to store an object of class A in the array. So, what's different about how the MFC CArray class allocates memory?
Second, how would I implement ConstructElements() for class A?
|
|
|
|
|
Hi,
Well the problem is the constructor.
If you create an array of objects then the default constructor is called for each object in your array. If you have no default constructor, that is a constructor with no parameters or all parameters set to default values, the construction of the array will fail.
I think that's the reason why you need to implement ConstructElements to make sure the right constructor gets called.
Regards
G. Steudtel
|
|
|
|
|
Hi,
Thanks for the response.
First, I'm confused about how allocating memory for a CArray works, and second I have no idea what I'm supposed to do to store objects with a dynamically allocated data member in a CArray.
1)My book says the default version of ConstructElements() allocates memory for the number of elements you want to store in the array, but it does not call a constructor for your objects. I assume that it must allocate memory using sizeof(<class name>) then. Now, how come a regular object can be stored in the CArray but you have to do something extra for an object with a dynamically allocated data member?
2) How do you implement ConstructElements() for the simple object with a dynamiclly allocated data member that I listed in my first post?
|
|
|
|
|
Hi all,
I am using the MMC Snap in object.
i have a property sheet (the mmc property sheet). i've added 3 pages to it
and displayed it. now i need to disable tab 2 and 3......
in the call back method CreatePropertyPages(LPPROPERTYSHEETCALLBACK lpProvider,long handle, IUnknown* pUnk, DATA_OBJECT_TYPES type) - i am creating the pages using
hr = lpProvider->AddPage(....)
my question is how do i disable this page now??? the LPPROPERTYSHEETCALLBACK doesn't supply a method to do that...
can any1 help?
thanks in advanced
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
