|
Thanks for suggesting that I use ShellExecuteEx. It gave me the handle that I needed to pass into WaitForSingleObject before calling CreateProcess.
|
|
|
|
|
Using Visual Studio 6.0, C/C++
=== Question 1
I am using the Workspace | ResourceView | Version
to input my current version info.
How do I read that info from within my code, so
that I can display it to the User on their demand?
=== Question 2
I am writing a Dialog-Based program. Is there any way to
show the User the About Box?
Many thanks,
Robert
|
|
|
|
|
Check out VerQueryValue() and GetFileVersionInfo() .
Robert Palma Jr. wrote:
I am writing a Dialog-Based program. Is there any way to
show the User the About Box?
Yes. If you used AppWizard, it was one of the choices.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thank-you David, I am working on it.
Sounds like I have to read the version
info FROM the file on the HD, rather than
being able to read it from the image that
is currently in memory.
Thanks again,
Robert
|
|
|
|
|
I am not sure about your statement.
If you have the module handle (an image in memory), I think you can load the version resource from that as well, meaning you CAN get the version information from an image in memory.
I have not done this before, but this is what I would try to do:
For an image in memory, you can try FindResource -> LoadResource -> LockResource -> Use pointer in call to VerQueryValue -> FreeResource .
I think you can use SizeofResource if you need total size of resource information (in lieu of GetFileVersionInfoSize ).
You are using FindResource, LoadResource, and LockResource instead of GetFileVersionInfo .
FreeResource is called when you are done so that the memory is freed.
|
|
|
|
|
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?
|
|
|
|