|
how to read an Excel files(.xls) with cell values using vc++...??
|
|
|
|
|
If you have excel installed on your system, read this[^]
If you don't have Excel installed, you should find some library which will do that for you (You could do it yourself, and I could even explain how, but that will take us too far).
Oh,and next time you post, try to be less polite and more descriptive in your title... 
|
|
|
|
|
Directly reading .xls files from Visual C++ would be cumbersome. I see two options:
- Use automation (there are a lot of articles about, here at
CodeProject, see, for instance, this list [^] ). - Export the
.xls file to .csv one format and then read the latter.
BTW: As posting guidelines suggest, a more meaningful message title would be appreciated.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: more meaningful message title would be appreciated.
Beat me to it 
|
|
|
|
|
I've used BasicExcel - A Class to Read and Write to Microsoft Excel[^] in the past, and it works pretty well. It's worth mentioning that I only needed to perform certain simple read operations.
Using excel automation would be ideal if you're going to do complex tasks.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
can u send me a sample project?
|
|
|
|
|
I cannot send you anything. However, the page I linked you to earlier has a sample project and some text that you can read up.
“Follow your bliss.” – Joseph Campbell
|
|
|
|
|
|
Dear gurus,
I'm having a problem in using ParseDisplayName.
1) I have a path of USB drive, such as: G:\
2) I pass this driver path into my function, which will call
ParseDisplayName to get PIDL item, as below:
LPITEMIDLIST CTemp::getItemIDList( CString p_strPath )
{
USES_CONVERSION;
if( p_strPath.IsEmpty() )
{
return NULL;
}
LPITEMIDLIST l_pIDL;
LPSHELLFOLDER pDesktopFolder;
if( ::SHGetDesktopFolder( &pDesktopFolder ) != NOERROR )
{
return NULL;
}
OLECHAR ochPath[MAX_PATH];
ULONG chEaten;
ULONG dwAttributes;
HRESULT hRes;
::MultiByteToWideChar( CP_ACP, MB_PRECOMPOSED, W2A(p_strPath), -1, ochPath,
MAX_PATH );
hRes = pDesktopFolder->ParseDisplayName( NULL, NULL, ochPath, &chEaten,
&l_pIDL, &dwAttributes);
pDesktopFolder->Release();
return l_pIDL;
}
3) The hRes result is 0x80070003 指定されたパスが見つかりません.
I don't know why it was failed.
I also try another way to solve this bug and I realize that, if i access to
this USB drive before calling ParseDisplayName, this method ParseDisplayName
always return good result, S_OK, such as:
a) Call the function ParseDisplayName at the first time, right after calling
ParseDisplayName again, the hRes result will be S_OK.
b) Declare a file path variable to one file in USB drive.
Call ParseDisplayName with this file path, then call ParseDisplayName with
the USB drive path, the hRes result will be S_OK.
c) Use while loop to browse each drive after using CSIDL_DRIVES, then
calling ParseDisplayName, the hRes result will be S_OK.
So can you help me to explain two issues:
1) Why does the ParseDisplayName method fail in this case ?
2) Why does the ParseDisplayName method success after accessing the USB
drive at first time?
If anybody here had the same situation like mine, please help me to clarify
the mystery surrounding this phenomenon.
I'm looking forward to seeing your replies.
Best regards,
Jetflower
|
|
|
|
|
I not sure but, but I think had faced the same problem some moths ago and at that time when I changed the CoInitializeEx to CoInitialize( or reverse ) the problem go fixed. Could you please try changing it?
|
|
|
|
|
Yes, that could be it. If your threading model is wrong, the shell won't be able to execute except when you call in to it, which explains that it does not see your drive before you allow it execute. See my other answer on this thread.
|
|
|
|
|
Your HRESULT indicates WIN32/PATH_NOT_FOUND. The only thing I can imagine is that the shell has not 'seen' your USB drive yet (i.e. it hasn't handled the mount on the G: reparse point and updated it's data structures). Calling into the shell once (through ::SHGetDesktopFolder) causes it to execute some code, and probably notice the mount event. Subsequent calls will the succeed.
|
|
|
|
|
|
Hi Friends,
I have an interesting question for all.
How can i restrict a dialog box(Modal or modeless) to stay within the
application boundaries?
Just like CView derived objects will not move out of application.
I know we can do it with OnMove(..) event handling.
But, i wanted to know whether there are any other direct means
like by setting some properties to CDialog class.
Please help me with this.
Regards,
K ARUN KUMAR
modified on Tuesday, May 4, 2010 5:30 AM
|
|
|
|
|
Add some code in your OnInitDialog() method (where you handle the WM_INITDIALOG message) to set your diaolg's window within the confines of its parent Window, assuming it is large enough.
It's time for a new signature.
|
|
|
|
|
Hi Richard,
As advised I have limited the size to be with in the application.
But, the problem comes when user is trying to move the dialog.
It goes out of application boundaries. I want a functionality
similar to CView child objects which stay with in the MainFrame.
|
|
|
|
|
Hi Arun,
To the best of my knowledge, it doesn't get any better than handling the move messages.
If you also handle the move/size messages of the parent, you'll know what your boundary dimensions without requesting them specifically every time your child dialog is moved. (unless of course mfc does this for you behind the scenes)
|
|
|
|
|
Hi enhzflep,
Yep.I have implemented the OnMove(..) solution for this.
But seriously searching for some direct method like
inheriting some poperties of CView which will make the dialog
to be constrained to be with in application.
Hope any one knows the better solution.
Thanks Mate.
|
|
|
|
|
K ARUN KUMAR wrote: Hope any one knows the better solution.
There isn't one, other than the suggestions you have already been given by other posters. You need to remember that a dialog should be a short lived window that allows interaction between your app and the user. If you want it to be longer lived and/or to restrict its positioning then you should make it a child window of your frame as described below.
It's time for a new signature.
|
|
|
|
|
A CFrameWind is the top window in an application. Embed a CDialog into a CFrameWnd so that
when the CFrameWnd is moved or minimized, the CDialog will also be moved and minimized.
CFrameWnd manages all of its child windows so that they fill its client
area. If you have a toolbar, a status bar and a CFormView they will all
be positioned and sized automatically by the CFrameWnd.
CFrameWnd
http://msdn.microsoft.com/en-us/library/4y17z36a(VS.80).aspx
|
|
|
|
|
Hi Micheal,
Thanks for your reply.
How to embed the CDialog into the CFrameWnd in SDI application
so that my requirement is accomplished.
I mean a bit of code.
Please help me. 
|
|
|
|
|
|
Nop. This does not work for me.
Any ways thanks for the help.
|
|
|
|
|
See if this helps.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Thanks David..
That worked.
One more thing.
If the dialog is a modeless dialog and if the
user goes back to the main frame window and moves the
window, the modeless dialog will go out of application.
So for this i have added the WM_MOVING event in MainFrame class.
void CMainFrame::OnMoving(UINT fwSide, LPRECT pRect)
{
//CFrameWnd::OnMoving(fwSide, pRect);
HWND hWnd = pDlg->GetSafeHwnd();
RECT rc;
RECT* pRc=&rc;
rc.left=rc.top=rc.right=rc.bottom=0;
LRESULT result = ::SendMessage(hWnd, WM_MOVING, (WPARAM)fwSide, (LPARAM)&rc);
}
and modified the WM_MOVING handler of Modeless Dialog as below.
void CModelessDlg::OnMoving(UINT fwSide, LPRECT pRect)
{
CDialog::OnMoving(fwSide, pRect);
CRect rcParent;
if(pRect->right==0) //Calin from MainFrame
GetWindowRect(pRect);
GetOwner()->GetWindowRect(rcParent);
// keep the child's left edge inside the parent's right edge
pRect->left = min(pRect->left, rcParent.right - m_nWidth);
// keep the child's left edge inside the parent's left edge
pRect->left = max(pRect->left, rcParent.left);
// keep the child's top edge inside the parent's bottom edge
pRect->top = min(pRect->top, rcParent.bottom - m_nHeight);
// keep the child's top edge inside the parent's top edge
pRect->top = max(pRect->top, rcParent.top);
// keep the child's right edge inside the parent's right edge
pRect->right = min(pRect->right, rcParent.right);
// keep the child's right edge inside the parent's left edge
pRect->right = max(pRect->right, rcParent.left + m_nWidth);
// keep the child's bottom edge inside the parent's bottom edge
pRect->bottom = min(pRect->bottom, rcParent.bottom);
// keep the child's bottom edge inside the parent's top edge
pRect->bottom = max(pRect->bottom, rcParent.top + m_nHeight);
if((rcParent.Width() < pRect->right - pRect->left) || (rcParent.Height() < pRect->bottom - pRect->top))
{
this->ShowWindow(SW_HIDE);
}
else
this->ShowWindow(SW_SHOW);
this->MoveWindow(pRect); //Added by Arun
}
Once again Thanks a lot David.....
modified on Wednesday, May 5, 2010 5:31 AM
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
