|
|
I'm using Excel Automation (#import method) to write data to an Excel file from my MFC application. The data export is working fine, with one exception.
The document for my app contains an enhanced metafile (as an array of bytes and a handle). I'd like to place this image in the Excel workbook I'm creating.
Can anyone help?
Thanks,
Greg Wellman
|
|
|
|
|
I need to process an INI file from a block of memory rather than a file on disk (the file's been read in and sent wholesale over a network). Are there equivalents to GetPrivateProfileString and the like which don't take a filename as an argument, rather a block of memory to work with? Any other suggestions?
Thanks all!
|
|
|
|
|
isn't writing the block of memory to a temporary INI file an option?
(don't know of any functions that work directly on memory)
- Indivara
"...This city desert makes you feel so cold.
It's got so many people but it's got no soul..."
- Gerry Rafferty, Baker Street
|
|
|
|
|
Yeah that was my first thought and it's what I'll probably do now. I don't really like the idea as it feels a little unclean.
It surprises me that there aren't alternative INI file methods which work on memory blocks.
Cheers!
|
|
|
|
|
So if the INI information came from a file already, why not use the INI functions to read it rather than circumvent them?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
The client sending the INI file data is dumb so I don't want it to interpret the INI file but send it over the network to the server which then interprets it.
Since I'm adding functionality and not writing a new system I wish to reuse the existing server's code which read INI files locally. E.g. there are functions in the server which exist:
ProcessINIFile(..., LPCSTR filename, ...)
And I want to extend these with:
ProcessINIFileFromMem(..., (void*)datablock, ...)
Having a set of INI file functions which worked on a block of memory (or even a CMemFile or similar) would make life much easier for me.
I agree that in any case it's not pretty but that's what you get when you're given a few tens of megs of a bunch of other people's code and asked to add bits to it in a hurry! 
|
|
|
|
|
I haven't tried this, but perhaps you can create a CMemFile[^] (which is derived from CFile).
Next, use the CFile::SetFilePath[^] to give it a name (MSDN says it won't actually create a file, but it gives a path name).
Then you may be able to use that path name in your GetPrivateProfileString call.
CMemFile myfile (with appropriate parameters);<br />
myfile.SetFilePath("C:\\mydir\\myfile.ini");<br />
GetPrivateProfileString(........, myfile.GetFilePath);
Hope that helps.
Karl - WK5M
PP-ASEL-IA (N43CS)
<kmedcalf@ev1.net>
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
It's worth a look although only for academic reasons since the hoops you need to jump through for this method are about the same as generating a safe temporary file, writing it out, feeding it back in and deleting it again. Guess the only advantage would be with this method, you can be sure the file will never actually be written out to disk whereas the second method the file might get flushed in its short existance.
|
|
|
|
|
krmed wrote:
Next, use the CFile::SetFilePath[^] to give it a name (MSDN says it won't actually create a file, but it gives a path name).
Then you may be able to use that path name in your GetPrivateProfileString call.
Hmm... no. That won't work. SetFilePath() will just store a path in the CFile object, so that later operations you call on it may use this value. But no one externally using this string as a path will be able to get to the CMemFile data.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I suggest writing it out as a temp file. When you create the file, use CreateFile and the option FILE_FLAG_DELETE_ON_CLOSE. As soon as the handle is closed (explicitly or the program crashing) the file will be deleted.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Hello, Im using the following line of code to draw a image in a window:
hSkinBmp=(HBITMAP)LoadImage(NULL, name, IMAGE_BITMAP, 0,0,LR_LOADFROMFILE);
HDC hdc = BeginPaint(hWnd6, &ps);
HDC hdcMem = CreateCompatibleDC(hdc);
HBITMAP hbmOld = (HBITMAP)SelectObject(hdcMem, hSkinBmp);
GetObject(hSkinBmp, sizeof(bm), &bm);
BitBlt(hdc, 2, 30, bm.bmWidth, bm.bmHeight, hdcMem, 0, 0, SRCCOPY);
SelectObject(hdcMem, hbmOld);
DeleteDC(hdcMem);
ReleaseDC(hWnd6,hdc);
EndPaint(hWnd6, &ps);
UpdateWindow(hWnd6);
--
And it works, the image is being drawn on the window, but then when try to run this function again to load a different image in the same window (like a slideshow), the second image is not shown on the window (the old image stays), untill I minimize and maximize the window.
What could be the reason for that?
Thx in advance
|
|
|
|
|
grep2 wrote:
And it works, the image is being drawn on the window, but then when try to run this function again to load a different image in the same window (like a slideshow), the second image is not shown on the window (the old image stays), untill I minimize and maximize the window.
I'm not sure if that's the problem, but I'd try invalidating the window before drawing the second image.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thank you both for taking you time to answer my question, but infact the first answer solved my problem, invalidating the window area worked fine.
|
|
|
|
|
Is this by any chance in an OnDraw handler?
If so, then you should not have the UpdateWindow() at the end of the function.
If not, then the BeginPaint and EndPaint are not the proper mechanism for getting your DC, you should use GetDC and ReleaseDC instead.
BeginPaint and EndPaint are ONLY for use in the WM_PAINT or OnDraw handlers.
This is most certainly a fundamental part of your problem.
|
|
|
|
|
Hello,
when you select more than one file in the windows-explorer you can show the properties by right-clicking and choosing the item "Properties" in the shell-menu.
I need to be able to do this within my application. I use the ShellExecuteEx-function to accomplish this task. But the problem is that i can only show the properties for the first selected file. I did a google-search and tried also msdn. Maybe someone has an idee.
Best regards
Tabor25
|
|
|
|
|
tabor25 wrote:
I use the ShellExecuteEx-function to accomplish this task.
What does this code look like?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Hallo David,
the code looks like this:
CString file = "";
POSITION pos = m_fileList.GetFirstSelectedItemPosition();
if (pos) {
file = m_fileTree.GetPath() + m_fileList.GetItemText(m_fileList.GetNextSelectedItem(pos), 0) + '\0';
}
if (file.GetLength()) {
SHELLEXECUTEINFO a_stInfo;
memset( &a_stInfo, 0, sizeof( a_stInfo ) );
a_stInfo.cbSize = sizeof( a_stInfo );
a_stInfo.lpVerb = _T("properties");
a_stInfo.lpFile = _T(file);
a_stInfo.fMask = SEE_MASK_INVOKEIDLIST;
ShellExecuteEx( &a_stInfo );
}
The member lpFile of the structure seems to carry only one filename. I tried to separate all selected files by using semicolon or \0 but without success. So at the moment i will show only the properties of the first selected file.
Maybe you or someone else has an idea...
Best regards
Tabor25
|
|
|
|
|
tabor25 wrote:
Maybe you or someone else has an idea...
Try IShellFolder::GetAttributesOf() instead.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
In a report style CListCtrl with multiple columns, I have traced on many CListCtrl events that the iSubItem of many ListCtrl STRUCTS is always zero eventhough the current subitem selected is on the columns other than the 1st column... For example:
<br />
void CResultsFormView::OnLvnItemchangedMyList(NMHDR *pNMHDR, LRESULT *pResult)<br />
{<br />
LPNMLISTVIEW pNMLV = reinterpret_cast<LPNMLISTVIEW>(pNMHDR);<br />
NMLVCUSTOMDRAW* pn=(NMLVCUSTOMDRAW*)pNMHDR;<br />
NMITEMACTIVATE* nm=(NMITEMACTIVATE*)pNMHDR;<br />
LPNMITEMACTIVATE temp = (LPNMITEMACTIVATE) pNMHDR;<br />
<br />
int item=temp->iItem;<br />
int subitem=temp->iSubItem;<br />
<br />
<br />
}<br />
<br />
Any thoughts on this problem...
"mustang this is ghostrider, requesting flyby..."
|
|
|
|
|
Hello
You can not select other than the 1st columns item in ListCtrl. The selection is always on the first column or it can be the whole row if you specified an appropriate style. So, for item changed event (and for most list control events) the subitem member will be 0.
Andrew
|
|
|
|
|
hello,
how can one adjust the position of the console window (default),for every c++ program in MS-visual studio 2003 environment.could there be a code for it ;is there any property settings.
my aim is to set the position of the console window at a set position for every c++ project without having to go to the dos prompt and adjust it every time.
regards
pratap
|
|
|
|
|
There is a directx driver in the windows system.
Thanks!
|
|
|
|
|
Does anyone know how to write strings into VS_VERSION_INFO?
For example i would like to change the InternalName of an executeable?
Not just version number...
any help would be much appreciated
Mepho
|
|
|
|
|
//Here goes.. this only copies ver from a src to dst file..
char srcfile[255], dstfile[255];
void changeVersion()
{
DWORD *dummy;
char *verinfo;
HANDLE hResource;
LONG lParam=0 ;
int size=0;
dummy=new DWORD;
size=GetFileVersionInfoSize(srcfile,dummy);
verinfo=(char*) malloc (size);
GetFileVersionInfo(srcfile,NULL,size,verinfo);
hResource = BeginUpdateResource(dstfile, FALSE);
if (NULL != hResource)
{
if (UpdateResource(hResource,
RT_VERSION,
MAKEINTRESOURCE(VS_VERSION_INFO),
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPVOID) verinfo,
size) != FALSE)
{
EndUpdateResource(hResource, FALSE);
}
}
}
//end code
regs
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
