|
u can try with "mciSendString" API function ...
anju
|
|
|
|
|
This should do:
HWND hWnd = MCIWndCreate(GetSafeHwnd(),
AfxGetInstanceHandle(),
MCIWNDF_NOMENU | MCIWNDF_NOPLAYBAR |
MCIWNDF_NOERRORDLG | MCIWNDF_NOOPEN,
szFilename);
MCIWndPlay(hWnd);
To stop playing:
MCIWndStop(hWnd);
MCIWndDestroy(hWnd);
|
|
|
|
|
Hello,
I'm working on WIA and trying to aquire image/audio/video from a digital camera. Everything looks fine like select the device and image. However, I still not problem tranfering file from the camera to the target machine. What I want is transfer the file from the camera to a file in the target, then I would like to get the file name from a STGMEDIUM and move to another location. According to MSDN, I set lpszFileName member of the pMedium structure to NULL to allow WIA to determine the file name and location for the new file. However, pIWiadataTransfer->idtGetData always returns STG_E_MEDIUMFULL and IWiaEventCallback::ImageEventCallback never be called. Do you know why? Thanks!
IWiaDevMgr* g_pIWiaDevMgr = NULL;
if (SUCCEEDED(CoCreateInstance(CLSID_WiaDevMgr, NULL, CLSCTX_LOCAL_SERVER,
IID_IWiaDevMgr, (void**)&g_pIWiaDevMgr)))
{
IWiaItem* pIWiaRootItem = NULL;
if (g_pIWiaDevMgr->SelectDeviceDlg(m_hWnd, StiDeviceTypeDefault, 0, NULL, &pIWiaRootItem) == S_OK)
{
LONG lItemCount = 0;
IWiaItem** ppWiaItem = NULL;
if (pIWiaRootItem->DeviceDlg(m_hWnd, 0, WIA_INTENT_NONE, &lItemCount, &ppWiaItem) == S_OK)
{
CWaiDataCallback* pWaiDataCallback = new CWaiDataCallback;
pWaiDataCallback->AddRef();
for (int i = 0; i < lItemCount; i++)
{
#if 0 // Do I have to setup some parameters for WriteMultiple?
IWiaPropertyStorage* pIWiaPropStg = NULL;
if (SUCCEEDED(ppWiaItem[i]->QueryInterface(IID_IWiaPropertyStorage, (void**)&pIWiaPropStg)))
{
PROPSPEC PropSpec;
PropSpec.ulKind = PRSPEC_PROPID;
PropSpec.propid = WIA_IPA_FORMAT;
PROPVARIANT PropVar;
PropVar.puuid = &WiaImgFmt_BMP;
pIWiaPropStg->WriteMultiple(1, &PropSpec, &PropVar, 2);
pIWiaPropStg->Release();
}
#endif
IWiaDataTransfer* pIWiadataTransfer = NULL;
if (SUCCEEDED(ppWiaItem[i]->QueryInterface(IID_IWiaDataTransfer, (void **)&pIWiadataTransfer)))
{
STGMEDIUM StgMedium = { 0 };
StgMedium.tymed = TYMED_FILE;
if (pIWiadataTransfer->idtGetData(&StgMedium, pWaiDataCallback) == S_OK) // *** Always return STG_E_MEDIUMFULL
{
pIWiadataTransfer->Release();
ReleaseStgMedium(&StgMedium);
}
}
ppWiaItem[i]->Release();
pWaiDataCallback->Release();
}
CoTaskMemFree(ppWiaItem);
}
pIWiaRootItem->Release();
}
g_pIWiaDevMgr->Release();
}
|
|
|
|
|
I dunno, but this months MSDN has a huge story on DirectShow to do exactly this, and it's available online at msdn.microsoft.com
It may be last months now, it's just come out in newsagents in Australia.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
I have emebedded a header control inside my main control but the header flickers madly despite having WS_CLIPCHILDREN specified in the main control. I have tried using SetRedraw() but that didn't work either...
These I figure are my options:
1) I owner draw the header control, but I'd really like to avoind this
2) I use InvalidateRect() somehow inside OnPaint handler of main control and invalidate the client rect - the header control height??? is this a possible solution...?
-----------------
| header control| <-- Ignore this part of client rect using InvalidateRect()...???
-----------------
| main control |
| |
| |
-----------------
Would this solve the header flicker problem...?
I've already double buffered the main control and handled OnEraseBkgnd() of main control properly
Ideas...?
Thanx! 
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
1 possibility springs to mind:
in both your OnPaint() and OnEraseBkgnd() handlers you call ExcludeClipRect() on the device context to clip out the header rect.
|
|
|
|
|
Throughout my code, after creating an application, I see comments in the header files such as:
//{{AFX_INSERT_LOCATION}}
// Microsoft Visual C++ will insert additional declarations immediately before the previous line.
#endif // !defined(AFX_XMAINWINDOW_H__CB25AA97_9522_4128_9EAE_946D14A1C1EB__INCLUDED_)
What purpose do they serve and I am required to keep them there? I'd prefer to remove them to keep my code as clean as possible for my own organization.
Thanks,
-Matt
|
|
|
|
|
There's an option when you start a new project...
"Would you like to generate source file comment?"
Yes, please
No, thank you
Selecting no generates a project without all the of the source code comments like you described...
|
|
|
|
|
Perhaps it's becuz i use learners edition, I can't afford the full package, but even when I select no comments I still get the comments mentioned by the original poster...
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
I think it only turns off the big comments like the stuff in InitDialog and InitInstance. The small stuff mentioned above is kept, especially the classwizard related stuff.
Michael
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
this is part of a header guard. it's a C/C++ trick to prevent a header from being included more than once during a compilation (to avoid multiple declarations). it matches up with the # if!defined and #define stuff at the top of your headers.
don't touch it. these aren't just comments.
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
I found this code to create a combobox (to be embedded in a toolbar)
CRect rect;
int nIndex = m_wndToolBar.GetToolBarCtrl().CommandToIndex(ID_COMBO);
m_wndToolBar.SetButtonInfo(nIndex, ID_COMBO, TBBS_SEPARATOR, 205);
m_wndToolBar.GetToolBarCtrl().GetItemRect(nIndex, &rect);
rect.top = 1;
rect.bottom = rect.top + 250 ;
if(!m_comboBox.Create(CBS_DROPDOWNLIST | CBS_SORT | WS_VISIBLE |
WS_TABSTOP | WS_VSCROLL, rect, &m_wndToolBar, ID_COMBO))
{
TRACE(_T("Failed to create combo-box\n"));
return FALSE;
}
I need an editbox, not a combobox. How do I modify this code ? Also, if I want to write stuff to this cEdit , how do I do that? Theres no m_Edit variable as I would have if it were on a form by itself, to do setwindowtext.
Thanks,
|
|
|
|
|
Actually I see that there will be an m_Edit variable so I suppose I can do a SetWindowText.
|
|
|
|
|
You'd change the first parameter to reflect the flags you wanted to apply to the edit box. They are listed in MSDN. The WS_ flags are generic and would remain.
Christian
We're just observing the seasonal migration from VB to VC. Most of these birds will be killed by predators or will die of hunger. Only the best will survive - Tomasz Sowinski 29-07-2002 ( on the number of newbie posters in the VC forum )
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
i use c++ to communicate with a java app through pipe (simply u can think the java app is javac.exe).
when the java app writes data to pipe (std io), i read data by c++ (Windows-not dos or unix).
with java 1.4, there is no any problem. but for jdk 1.3 or 1.2, i have trouble:
if the java app exits with no suitable signal, c++ doesn't know (if jdk 1.4, c++ knows) and is still waiting there.
i think there must be some idea to know because another side of pipe is closed.
key functions used are:
CreatePipe, CreateProcess, ReadFile.
i think ReadFileEx should be better but i got no idea about it after testing.
thx for ur suggestion.
 ;);P  ((       
includeh10
|
|
|
|
|
Are you calling CloseHandle on the pipe handles when you are done with them? This should signal to either the Write or the Read side that the pipe has been closed/broken and you can cleanup/exit.
i.e.:
DWORD dwBytesToRead = 0;
<P></P>
BOOL bStatus = ReadFile( m_hReadPipe, &SomeData, dwBytesToRead, &dwBytesRead, NULL );
<P></P>
if( bStatus && (dwBytesRead > 0) )
{
<P></P>
CloseHandle(m_hReadPipe);
m_hReadPipe = INVALID_HANDLE_VALUE;
}
else
{
if( m_hReadPipe != INVALID_HANDLE_VALUE)
{
CloseHandle(m_hReadPipe);
m_hReadPipe = INVALID_HANDLE_VALUE;
}
}
Roger Stewart
"I Owe, I Owe, it's off to work I go..."
|
|
|
|
|
I had similar problems with a C++ client. The read did not always
give the right error codes to see if the conn was broken.
I used named pipes and there is a very handy function named
PeekNamedPipe
if PeekNamedPipe returns an error, You can be sure that the conn is lost.
If no data is pending, nothing happens.
|
|
|
|
|
I am having some problems on VS.Net
I've just created a popup menu with some IDs (ID__LAUNCHEXPLORER, ID_CLOSEAPP) in the resource editor.
Within VS.Net development environment, I go to the properties page and select 'Menu Commands' then expand the listbox that has ID__LAUNCHEXPLORER so it has the COMMAND field visible. When I then click on the combo box dropdown list and click on 'add' the following error message occurs: "Add/Remove of the function is impossible, because the parent class code is read only"
I can (and did) add the functions manually and type in the mapping through the message map manually too (which works) but I haven't a clue why VS.net's doing this? 
Anyone any ideas? Bring back ClassWizard!  VS.Net seems to want so many windows open at once I might be persuaded to buy a 24" monitor or something just so I can see the postage stamp that's left for my code! 
see ya
Adam.
"I spent a lot of my money on booze, birds and fast cars. The rest I just squandered"
George Best.
|
|
|
|
|
I have a MDI project derived from CFormView. My first form (CMyProjView) links a second form (CForm2) which contains an embedded property sheet.
My data is located inside my Document class (CMyProjDoc) and I want to access
it from the property sheet inside CForm2.
I tried this but get an access violation; probably because the pointer reaching CForm2 only.
CMyProjDoc* pDoc=(CMyProjDoc*)GetTopLevelFrame()->GetActiveDocument();
ASSERT_VALID(pDoc);
pDoc->GetData(0);
How to get a pointer to my Document class?
Any suggestions?
Thanks
Kash
|
|
|
|
|
can you just pass a doc pointer from your view to the property sheet?
-c
For men use, if they have an evil turn, to write it in marble:
and whoso doth us a good turn we write it in dust.
-- Sir Thomas More
|
|
|
|
|
First off, thanks for all the help you all are giving me. I've, however, tried all your suggestions without success. Here's the problem: I want to populate dialog fields with data from my Document class. What I did makes logical sense, but it gives me an 'illegal operation' message when I run the program. Here is the code:
BOOL CSetupDlg::OnInitDialog() {
CDialog::OnInitDialog();
//get pointer to Document
CSEIDoc *pDoc;
//initialize combo box
m_nPeriodDlg.SetCurSel(pDoc->m_nPeriod);//assertion failure here
//initialize check buttons
m_cbCheckGrowth.SetCheck(pDoc->m_bCheckGrowth);//and here
m_cbCheckFeed.SetCheck(pDoc->m_bCheckFeed);//and here
//initialize slider control
m_sdrHaloScale.SetRange(0,15);
m_sdrHaloScale.SetPos(XDIM/96);
return TRUE;
}
How can I overcome this? Thanks again,
Ralf.
ralf.riedel@usm.edu
|
|
|
|
|
CSEIDoc *pDoc; This only declares a pointer to your document class, but does not actually retrieve it. Try with
pDoc=(CSEIDoc *)((CFrameWnd *)(AfxGetMainWnd())->GetActiveView()->GetDocument());
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I've tried to use CSEIDoc *pDoc = CSEIView::GetDocument; The error message was 'illegal call of non-static member function'. The statement you suggested '(CSEIDoc *)((CFrameWnd *)(AfxGetMainWnd())->GetActiveView()->GetDocument());' gives me a ''GetActiveView' : is not a member of 'CWnd'' error. Any idea how to fix this? Thx,
Ralf.
|
|
|
|
|
CSEIDoc *pDoc = (CSEIDoc *)(((CFrameWnd *)AfxGetMainWnd())->GetActiveView()->GetDocument()); Parentheses were not quite correct.
PS: Don't mean to be rude, but this was easy enough for you to fix on your own. I'd suggest you revise your knowledge about casting syntax. If you don't understand what this line of code is doing, please take the time to analyze it --getting help without trying to acquire some expertise on the way won't make you a better programmer.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
RalfPeter wrote:
//get pointer to Document
CSEIDoc *pDoc;
Can you see the problem? You declared a pointer pDoc of the type CSEIDoc, but did not initialize it. Later, you try to access the members of the object the pointer is supposed to point to, but does not, since it has not been made to do so.
Regards,
Rohit Sinha
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
