|
Hi Mike,
Well, I have no idea about the dll thing. Since you talked about something related to soundcard, have you tried "The Synthesis ToolKit in C++ (STK)" library before? You can download it from:
http://ccrma.stanford.edu/software/stk/[^]
I don't know whether it fit your application, but for mine, it just perfect.
Regards,
Chris
|
|
|
|
|
Well one of the advantages is that with a DLL you can just add the library to your project and include the corresponding header file and then you are able to access the functionality in that DLL. It seems annoying to constantly copy the same header+implementation file to you project.
Er zit een korstje op mijn aars.
|
|
|
|
|
If you use them in a lot of your applications, it's worth making DLLs. If you don't, then no, it's not.
There are "trade-offs", but there are no real advantages unless a LOT/all of your apps use those DLLs.
Yes, you can use threads in DLLs.
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I writting a MFC app to read header infos like http://codeproject.com/bitmap/iptc.asp[^]
when i click F5 to compile,program shows a box :
"Unhandled Exception in JPEGHeader.exe,0xC0000005 :Access Violation
How can i debug ??
Plzz help me,thanks so much!!
|
|
|
|
|
Hi;
for (int i=0; i<21; i++)
cout << i<<" " ;
return 0;
My question is how can I get the outputs in bold form?
|
|
|
|
|
I haven't used it myself but you may want to check out the SetConsoleTextAttribute API.
Steve
|
|
|
|
|
Em... I tried this approach. It works! I learn a new skill from you.
Thank you, Steve.
Thanks to the person who post this question too.
Regards,
Chris
|
|
|
|
|
Hello community!
I've recently taken on a new task of rewritting an old control panel (originally written w/ Borland). The basic idea is to do the following:
-Read control settings from a database
-Dynamically create multiple forms based on the database
-Dynamically populate multiple controls on the forms
-Changes/updates to the control are taken from RAM on a PCI device.
-Beyond manipulating controls, I have to communicate some data over RS232 and Ethernet (basically, I need to write a terminal program).
The task seems simple, but I'm a programmer from a more embedded/unix world. My experience in VC only goes as far as the extent of one of those "Learn VC in 21 days" type books.
The main difficulty I'm having right now, is overcoming the learning curve to the MFC. Since my application is primarily form based, it would seem logical to use a simple Dialogs Application - however, I've been toying with the idea of using the Doc/View architecture with multiple CFormViews. I can see some benefit of using the MDI interface and binding each of the my control panels to a seperate CDocument. I would, however, need to instantiate each of these CDocuments and CFormViews dynamically, as their properties/content depend entirely upon the database.
Any insight you could provide to help me choose an architecture and get me started along the right direction is appreciated.
Thanks!
Embedded
|
|
|
|
|
Dear All,
how can I get a pointer to DC (that is associated with the View):-> from the document class? I need a pointer to DC to do some manipulation... I am using:
CDC *pDC = AfxGetMainWnd()->GetDC();<br />
....<br />
....<br />
AfxGetMainWnd()->ReleaseDC();
but it's not working as expected...
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
You can use CDocument::GetFirstViewPosition / GetNextView to get the view windows. Then, as CView inherits from CWnd, you can use CWnd::GetDC to get the view's DC.
If you are in a SDI app, you can get the view straight away. In am MDI view, you potentially need to iterate ythrough them.
Another alternative, is to us CDocument::UpdateAllView (...) with a custom lParam, and let the views draw on themselves. A CDocument is supposed to have no idea about how its data is displayed - thats the point of separating them!
Iain.
|
|
|
|
|
Iain Clarke wrote: A CDocument is supposed to have no idea about how its data is displayed
Yup! but we break the rules sometimes! 
Actually, I just need a refrence to a DC (the View's DC) to set some parameters, I am not doing any drawing...
- A programmer's national anthem; "AAAAAHHHHH!!!!"
|
|
|
|
|
Hi guys i want to save a file from a dialog box. II have my save dialog and all but when i save a file, i get only a blank file. is it bcoz of the CREATE_NEW attribute of the createFile method??? how do i save data in that file
please help
|
|
|
|
|
what other actions do you take to save the data?
|
|
|
|
|
what dialog box ? a CFileDialog dialog ?
When you create the file with CreateFile, you write something in it ? or you simply create it and hope that something will put data in the file ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Make sure you set the CREATE and/or WRITE flag(s) before you write something to that file. If you need a Save Dialog I recomend you Davide Calabro's CFileDialogST[^] Good luck!
|
|
|
|
|
Hello all.
I'm trying to get the source-code from the active text-editor window on the VS IDE.
I'm using the COM interface as follows:
<br />
CComPtr<EnvDTE::Document> ADocument;<br />
m_pDTE->get_ActiveDocument(&ADocument);
But what's next ? EnvDTE::Document does not contain any methods for text retrieval.
Any help would be appreciated.
|
|
|
|
|
Hi all,
I have a Win32/windowless/GUI-less/MFC-less application that currently sends a bit of data through HTTP via winsock.
Essentially, in some buffer, I format the standard HTTP headers in plain text, then the actual data to send, then send the whole thing via winsock, and close the connection. Relatively straightforward.
Now I've been asked to replace this so the program uses HTTPS instead, and to do this I have been provided with nothing more than a link to W3MFC[^], whose goal I suspect was not fully understood by The Powers That Be (who sent me the link).
My understanding of this library is that it essentially derives some classes from MFC's CSocket, and requires the library from OpenSSL.org, to implement some wrapper around all of this.
I'm not allowed to rely on MFC, as my final EXE must remain as small as possible--statically linking is not acceptable, and I don't have the luxury either of being able to rely on an external DLL that may or may not be there. It's just "gotta run" on anything from Win95 onward. This EXE's been in production for nearly 6 years.
So much for this library. I've started looking at OpenSSL itself.
On the server side, .NET is already being used to implement the site itself, provide access to a database, etc. I'm not familiar (yet) with .NET, and can only assume .NET already has some library (built in?) that can handle HTTPS clients...Either way, I'm not the one who's going to implement the server, but I can only assume an SSL server can handle any SSL client, provided the syntax is correct (just like any web server can handle any web browser, provided the requests adhere to the HTTP standard)...
Given the requirements above and this nebulous idea of "replacing HTTP with HTTPS"--where do I even start?
|
|
|
|
|
Daniel.
I recently had to add SSL support to a custom mail client of mine, and though this is an MFC app, I was using an old socket class in plain vanilla C++. In the end I used the MS SSPI library, but this probably won't work on Win9x unfortunately, so is probably of little use to you. I found some sample ATL code that used SSPI with a raw socket, which made life easier. I don't think HTTPS will be that different from POP/SMTP TLS/SSL, except you have to worry about certificates, etc.
|
|
|
|
|
> In the end I used the MS SSPI library, but this probably won't work on Win9x unfortunately
Well, to be honest, Win9x support is getting to be more of a "nice to have" feature at this point as there aren't too many 9x-based machines out there--we may be able to get away with telling our 9x customers that SSL will be for NT+ only.
I'll definitely look into MS's SSPI; in the meantime, if you could forward any relevant link or sample, that would be very much appreciated.
Thanks.
PS - anybody has experience with OpenSSL? Am I wasting my time even looking at that?
|
|
|
|
|
I'm not familiar with CSocket, but winsock works wells with OpenSSL API.
Kuphryn
|
|
|
|
|
> I'm not familiar with CSocket,
I'd rather not use it. My current code doesn't rely on MFC, and I don't want to introduce this dependency at this point in the program's life.
> but winsock works wells with OpenSSL API.
I "sorta" got this to run with the OpenSSL library. Compiling the library (with ms\do_ms.bat)generated two files, which got copied in the Windows directory: libeay32.dll (668KB), and ssleay32.dll (152KB). Do these figures sound correct to you? My compiled EXE is under 500KB, and I would hate to see it double in size "just" because of the SSL library it's using. I'm not allowed to require clients to have the DLLs pre-deployed (eg, preinstalled), so I'd have to embed the DLLs in the EXE itself and then extract/execute/delete them when done...
I'm beginning to see OpenSSL as a dead end. It's hard for me to believe an SSL library can't be compiled to under 50KB worth of binaries.
I'm starting to take a closer look at MS's SSPI as Robert suggested. If you can convince me otherwise, by all means, please tell me the library can be made smaller...
-- modified at 16:51 Monday 20th March, 2006
|
|
|
|
|
Is possible to transmit some parameters to a function in dll
am
|
|
|
|
|
|
Hello,
I want to overload only the IPropertyPage::Apply() part of the COlePropertyPage, and keep the call to other IPropertyPage method managed by COlePropertyPage
I have some thing similar to this:
class COleBaseParamPage : public COlePropertyPage
{
...
DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_PART(PropertyPage, IPropertyPage)
INIT_INTERFACE_PART(COleBaseParamPage, PropertyPage)
STDMETHOD(Apply)();
STDMETHOD(SetPageSite)(LPPROPERTYPAGESITE);
...
END_INTERFACE_PART(PropertyPage)
}
BEGIN_INTERFACE_MAP(COleBaseParamPage, COlePropertyPage)
INTERFACE_PART(COleBaseParamPage, IID_IPropertyPage, PropertyPage)
END_INTERFACE_MAP()
STDMETHODIMP COleBaseParamPage::XPropertyPage::SetPageSite(LPPROPERTYPAGESITE pPageSite)
{
METHOD_PROLOGUE_EX(COleBaseParamPage, PropertyPage)
// here I would call the original COlePropertyPage::XPropertyPage::SetPageSite()
}
I have made some test for calling the original COlePropertyPage::XPropertyPage::SetPageSite() by using the _GetBaseInterfaceMap() to get it's adress, but without success. I can't figure how to optain the original COlePropertyPage::XPropertyPage object adress
If someone have a suggestion, I will be very happy...
Thanck's
---
for information, I'm using some code issued from the CmdTarget code, like:
#define GetInterfacePtr(pTarget, pEntry) \
((LPUNKNOWN)((BYTE*)pTarget + pEntry->nOffset))
static LPUNKNOWN _getInterface(REFIID _iid, LPVOID me, const AFX_INTERFACEMAP* pMap)
{
const void* iid = &_iid;
DWORD lData1 = ((IID*)iid)->Data1;
do
{
const AFX_INTERFACEMAP_ENTRY* pEntry = pMap->pEntry;
ASSERT(pEntry != NULL);
while (pEntry->piid != NULL)
{
if (((DWORD*)pEntry->piid)[0] == lData1 &&
((DWORD*)pEntry->piid)[1] == ((DWORD*)iid)[1] &&
((DWORD*)pEntry->piid)[2] == ((DWORD*)iid)[2] &&
((DWORD*)pEntry->piid)[3] == ((DWORD*)iid)[3])
{
// check INTERFACE_ENTRY macro
LPUNKNOWN lpUnk = GetInterfacePtr(me, pEntry);
// check vtable pointer (can be NULL)
if (*(DWORD*)lpUnk != 0)
return lpUnk;
}
// entry did not match -- keep looking
++pEntry;
}
#ifdef _AFXDLL
} while ((pMap = (*pMap->pfnGetBaseMap)()) != NULL);
#else
} while ((pMap = pMap->pBaseMap) != NULL);
#endif
return NULL;
}
STDMETHODIMP COleBaseParamPage::XPropertyPage::SetPageSite(LPPROPERTYPAGESITE pPageSite)
{
METHOD_PROLOGUE_EX(COleBaseParamPage, PropertyPage)
IPropertyPagePtr p = _getInterface(IID_IPropertyPage, pThis, pThis->_GetBaseInterfaceMap());
p->SetPageSite(pPageSite);
return S_OK;
}
This code do recursive call, because the 'me' parameter is not the COlePropertySheet adress (I admit I'm a little lost with all these stuff)
|
|
|
|
|
Hello,
I want to overload only the IPropertyPage::Apply() part of the COlePropertyPage, and keep the call to other IPropertyPage method managed by COlePropertyPage
I have some thing similar to this:
class COleBaseParamPage : public COlePropertyPage
{
...
DECLARE_INTERFACE_MAP()
BEGIN_INTERFACE_PART(PropertyPage, IPropertyPage)
INIT_INTERFACE_PART(COleBaseParamPage, PropertyPage)
STDMETHOD(Apply)();
STDMETHOD(SetPageSite)(LPPROPERTYPAGESITE);
...
END_INTERFACE_PART(PropertyPage)
}
BEGIN_INTERFACE_MAP(COleBaseParamPage, COlePropertyPage)
INTERFACE_PART(COleBaseParamPage, IID_IPropertyPage, PropertyPage)
END_INTERFACE_MAP()
STDMETHODIMP COleBaseParamPage::XPropertyPage::SetPageSite(LPPROPERTYPAGESITE pPageSite)
{
METHOD_PROLOGUE_EX(COleBaseParamPage, PropertyPage)
// here I would call the original COlePropertyPage::XPropertyPage::SetPageSite()
}
I have made some test for calling the original COlePropertyPage::XPropertyPage::SetPageSite() by using the _GetBaseInterfaceMap() to get it's adress, but without success. I can't figure how to optain the original COlePropertyPage::XPropertyPage object adress
If someone have a suggestion, I will be very happy...
Thanck's
---
for information, I'm using some code issued from the CmdTarget code, like:
#define GetInterfacePtr(pTarget, pEntry) \
((LPUNKNOWN)((BYTE*)pTarget + pEntry->nOffset))
static LPUNKNOWN _getInterface(REFIID _iid, LPVOID me, const AFX_INTERFACEMAP* pMap)
{
const void* iid = &_iid;
DWORD lData1 = ((IID*)iid)->Data1;
do
{
const AFX_INTERFACEMAP_ENTRY* pEntry = pMap->pEntry;
ASSERT(pEntry != NULL);
while (pEntry->piid != NULL)
{
if (((DWORD*)pEntry->piid)[0] == lData1 &&
((DWORD*)pEntry->piid)[1] == ((DWORD*)iid)[1] &&
((DWORD*)pEntry->piid)[2] == ((DWORD*)iid)[2] &&
((DWORD*)pEntry->piid)[3] == ((DWORD*)iid)[3])
{
// check INTERFACE_ENTRY macro
LPUNKNOWN lpUnk = GetInterfacePtr(me, pEntry);
// check vtable pointer (can be NULL)
if (*(DWORD*)lpUnk != 0)
return lpUnk;
}
// entry did not match -- keep looking
++pEntry;
}
#ifdef _AFXDLL
} while ((pMap = (*pMap->pfnGetBaseMap)()) != NULL);
#else
} while ((pMap = pMap->pBaseMap) != NULL);
#endif
return NULL;
}
STDMETHODIMP COleBaseParamPage::XPropertyPage::SetPageSite(LPPROPERTYPAGESITE pPageSite)
{
METHOD_PROLOGUE_EX(COleBaseParamPage, PropertyPage)
IPropertyPagePtr p = _getInterface(IID_IPropertyPage, pThis, pThis->_GetBaseInterfaceMap());
p->SetPageSite(pPageSite);
return S_OK;
}
This code do recursive call, because the 'me' parameter is not the COlePropertySheet adress (I admit I'm a little lost with all these stuff)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
