|
Here's the problem...
There are two DLLs, one is storing data and the other needs access to the same data. The data is not a fixed size - right now I'm adding objects to a vector to keep track of it. The DLL with the data is called by an application, not the other DLL that needs the data.
Using a shared data section -
#pragma data_seg(".shared")<br />
vector<SignalGroup> theVector; <br />
#pragma data_seg()
and using the linking command /SECTION:.shared,S
- doesn't work, I'm guessing because of the variable size of the vector.
Is memory-mapping the right route to take here? The size of the data block has to be specified with that as well I believe...
Thanks for any help.
|
|
|
|
|
I believe that creating a shared memory segment using Memory Mapped files is one of the better ways of sharing data between processes. You have to be careful about the size though, because that kind of shared area uses the paging file (IIRC).
Watch out for syncronizing access to the area, if you need to add and remove items from it.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Hello!
Im trying to convert an HBITMAP from a third party image class.. so that i can draw the image in a CView.. I have initialized all properties already except the bmiColors of the BITMAPINFO*. How do you initialize this, lets say for example i have 256 colors and 16 bits in the image? do i use RGB values or realized palettes?
having a hard time with this one?
tnx in advance.
maverick
|
|
|
|
|
16-bit image = no palette
256 colors implies an 8-bit image
the palette lives between the end of the BITMAPINFOHEADER and the start of the pixel data. you can find its size by calculating (1 << bmih.biBitDepth) * sizeof(RGBQUAD) .
a little pointer arithmetic will get you to the start of the palette: (address of the BITMAPINFOHEADER + sizeof(BITMAPINFOHEADER))
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
i got the position/address of the palette.. what do i do next? what values do i initialize i wih ?
|
|
|
|
|
Hello,
Is it possible to add an executable to a VC++ project. The project I am working on makes use of various smaller programs. Is there any way to combine these programs into my own program so that they don't have to be present in the same location as my own executable? I hope this makes sense.
Thanks very much,
dlarkin77
|
|
|
|
|
You can add them as resources, unpack them to the temp directory, run them and delete them after that.
Do you have the source code of these small executables?
If so, then why don't you include then into the main app?
Don't try it, just do it! 
|
|
|
|
|
Hi Alexander,
Would you have some sample code to do this? I don't have the source code for these executables.
Thanks very much,
dlarkin77
|
|
|
|
|
If Alexander's suggestion is what you are after, see here for an example.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I use the following line to create my file:
CStdioFile fileWrite (m_sSave, CFile::modeCreate);
and the following line to write to file:
fileWrite.Write (n_buffer, sizeof (n_buffer));
Where n_buffer is a nonempty CString. But even though the file gets created successfully it stays empty. Am I missing some command?
|
|
|
|
|
now I added fileWrite.Close(); instead of relying on default destructor, and it keeps throwing "Disk full while accessing C:\...\file" at me despite the fact that I have 50 GB of free space left on my computer.
|
|
|
|
|
Anonymous wrote:
it keeps throwing "Disk full while accessing C:\...\file" at me despite the fact that I have 50 GB of free space left on my computer.
Strange, since you are only writing 4 bytes.
fileWrite.Write (n_buffer, sizeof (n_buffer));
"sizeof (n_buffer)" returns the size of the pointer 'n_buffer'
(which is 4 bytes on a 32-bit system) not the size of the buffer.
Steve T
|
|
|
|
|
FlyingTinman wrote:
"sizeof (n_buffer)" returns the size of the pointer 'n_buffer'
n_buffer is a CString object, not a pointer. Your point about misusing sizeof is still valid, however.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Try:
CFile::modeCreate | CFile::modeWrite
 Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Ok, adding modeWrite got rid of the Disk Full error. Also, I didn't know that sizeof only gave the size of the pointer to the string, which would explain why I get gibberish in the file after adding modeWrite. However, n_buffer.GetLength() produces no output in the file, so that doesn't seem to be the correct option either. My guess is that it's not working because Windows 2000 and XP use unicode representation and each letter ends up being 2 bytes, so the actual sizeof is doubled? If so, what fix could I apply so that it would work with both: current and old versions of windows that used ANSI? And if my guess is completely unrelated to the actual problem, can anyone suggest what's actually causing this? Thanks.
|
|
|
|
|
Apparently the problem is with the file's encoding, and not with the OS. The original file spits out gibberish (I'm guessing it uses ANSI encoding), when I copy/paste all its contents into a new file, and run the exact same routine on it, the new output is fine. Is there a way to run a check on the file's encoding before it's processed?
|
|
|
|
|
I didn't realize you were storing a CString within a CStdioFile. Wouldn't WriteString be your best option?
<br />
file.WriteString(n_buffer);<br />
Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
|
|
|
|
|
Jack Squirrel wrote:
Wouldn't WriteString be your best option?
Only if carriage return–linefeed pairs needed to be translated.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Anonymous wrote:
fileWrite.Write (n_buffer, sizeof (n_buffer));
If you are going to use Hungarian notation (I assume that was your attempt), at least use it correctly. Seeing n_buffer indicates to me an int or short type.
Try:
fileWrite.Write(n_buffer, n_buffer.GetLength() * sizeof(char)); CFile::Write() is expecting a byte count while CString::GetLength() returns a character count.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Yeah, I know I didn't use correct hungarian notation, what that n is meant to stand for is new buffer, because I have two of them. Also, what if the file uses a different encoding than the OS? How do I test that?
|
|
|
|
|
Anonymous wrote:
Also, what if the file uses a different encoding than the OS? How do I test that?
I'm not sure I follow. The OS is not concerned with how an application write to or reads from a file. Perhaps you should elaborate on your concern.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Well, the original file doesn't get processed right, it spits out blocks (gibberish) after being proccessed. However, copy/pasting its contents into a new file and processing new file results in correct output. My guess is that although I'm using Windows 2000, the machine that the file was created on used a different encoding than the one my OS uses when it creates a new file.
|
|
|
|
|
Since CStrings are TCHAR-capable, I would suggest changing the code to:
fileWrite.Write(n_buffer, n_buffer.GetLength() * sizeof(<code>TCHAR</code>));
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Tip for new SUV drivers: Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
I want to use SetTitle function but compiler gives that error "C2065 'SetTitle' : undeclared identifier.
How can i use this function.
|
|
|
|
|
I found a solution, but i guess it is not a good solution.
I have remove these form stdafx.h
#ifndef _WIN32_IE // Allow use of features specific to IE 4.0 or later.
#define _WIN32_IE 0x0400
// Change this to the appropriate value to target IE 5.0 or later.
#endif
i dont understand but it seems to work good.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
