|
Have you tried and failed? In theory it's supposed to work, according to the Boost page.
Kevin
|
|
|
|
|
Tried with 1.33. Most of it built but some of it didn't and there were some buffer overruns during the build. I might try one of the betas.
Thanks!
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
With beta 2, yes.
I just used bjam with a toolset of "vc-8_0", like it says on the Getting Started page. At that time, there were a few problems -one of the libraries wouldn't build (but I didn't need it) and also they tried to build a statically linked or single-threaded CRT version when there isn't one.
Anyway, it just worked?
Stuart Dootson
'Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p'
|
|
|
|
|
Didn't use the beta. I used 1.33. Several buffer overruns and as you stated some of the libraries didn't build.
Moving to the beta!
Thanks.
ed
~"Watch your thoughts; they become your words. Watch your words they become your actions.
Watch your actions; they become your habits. Watch your habits; they become your character.
Watch your character; it becomes your destiny."
-Frank Outlaw.
|
|
|
|
|
Bit of a misunderstanding - I meant I'd used beta 2 of Visual Studio 2005, rather than the retail version...I've only built released builds of 1.32 & 1.33, no betas.
Sorry for any confusion!
|
|
|
|
|
I have built boost_python and boost_signals with VC 2005 Express without problems. The other libs did not compile. (boost_1_33_0).
-- modified at 4:28 Monday 12th December, 2005
|
|
|
|
|
Hi,
I am working on ATL Project where i am getting this link error. I used the below setting while creating the project MFC+Merge Proxy/Stub. How to eliminate this error
Linking...
mfcs71d.lib(dllmodul.obj) : error LNK2005: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj)
mfcs71d.lib(dllmodul.obj) : warning LNK4006: _DllMain@12 already defined in MSVCRTD.lib(dllmain.obj); second definition ignored
Creating library Debug/SASIExport.lib and object Debug/SASIExport.exp
Thanks,
Cool Ju 
Cool Ju
|
|
|
|
|
I solved the problem. The problem is the order in which these libraries are inlcuded. I got a good article from Codeguru which helped me to solve this bug.
this is the link[^]
Anyway Thanks,
Cool Ju
Dream Ur Destiny
|
|
|
|
|
Hi,
I have a method the fires an event. But I have not been able to find the way to capture the event in VC++. I can get this event through VB but I need it in VC.
Please help.
Thanks in advance.
|
|
|
|
|
|
Thanks Eric. Wasn't what I was look 4 but appreicated the help.
|
|
|
|
|
Hello w_logan,
What you want to develop is an "Event Sink". If you are using ATL, create a class that inherits from IDispEventImpl. You will also need to include the BEGIN_SINK_MAP(), SINK_ENTRY_EX() and END_SINK_MAP() macros. Of course, your class will have to implement the event function itself. The great thing about the sink map macros is that you choose only those events that you want to supply handlers for. You do not need to implement handlers for all the events.
An alternative to using the above-mentioned ATL constructs is to use my TEventHandler class. Please read my article :
"Understanding COM Event Handling" (http://www.codeproject.com/com/TEventHandler.asp[^])
- Bio.
|
|
|
|
|
Thanks Bio. I had already read the article when I was doing my research. It was a great article.
I had initially intended to use "Event Sink" to solve my problem but I work around it by another mean.
Actually, I had a COM DLL with multiple objects within it. But I had only expose the main object class. My problem arise when one of my internal object needs to fire a event to the app using my DLL. As only the main interface is expose, the internal object can't fire the event direct to the app.
I was trying use the main object to sink the event and fire it again. But I never really got the way for doing the sink coding properly. Nonetheless, I worked around it by send the point to the main object inwards to the internal object and use this pointer to fire the event. It may not be the proper way to solve the problem but it solve my problem for now.
Nonetheless, thanks for the help again. (If you remember, you had help this fellow Singaporean on several other occasion.)
Cheers
-- modified at 22:09 Tuesday 22nd November, 2005
|
|
|
|
|
Hello w_logan,
Yes, I remember you. We had corresponded som months ago I believe. How are you ? I hope you're doing well. Just a few comments :
>> Actually, I had a COM DLL with multiple objects within it. But I had only expose the main object class. My problem arise when one of my internal object needs to fire a event to the app using my DLL. As only the main interface is expose, the internal object can't fire the event direct to the app.
Comment : you may want to re-think about the design of your interfaces. Since the internal object needs to fire an event to your app, this may signal a need for the internal object's interface to be exposed to the app directly.
On the other hand, if the internal object is meant to be internal afterall, then its events should rightfully be handled internally as well. The main object should be the handler for the event and it is a completely separate matter whether or not this main object ought to further "relay the message" to the app.
>> I was trying use the main object to sink the event and fire it again. But I never really got the way for doing the sink coding properly.
Comment : there are many ways to connect sinks with sources I guess. Just be careul about inter-thread event firing which will require marshaling. However, if everything happens on one thread, marshaling may not be so important.
>> Nonetheless, I worked around it by send the point to the main object inwards to the internal object and use this pointer to fire the event. It may not be the proper way to solve the problem but it solve my problem for now.
Comment : again, be careful about directly passing interface pointers here and there espacially across threads. Marshaling may be required.
- Bio.
|
|
|
|
|
Lim Bio Liong wrote: - Bio.
Hai Sir,
I am waiting for an article on IDispEventImpl from your side  ...
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hello Alok !
How are you dear friend ? Enthusiastic as usual. It's very contagious
Yes, it'd be great if there's an in-depth dissertation on ATL's IDispEventImpl. Especially one that can show how to use it in MFC apps. I'll see if I can get some time on this.
But how about yourself, Alok ? Would very much like to see you contribute another winner !
Best Regards,
Bio.
|
|
|
|
|
Lim Bio Liong wrote: How are you dear friend ? Enthusiastic as usual. It's very contagious
Ohh I am Alright Sir!.. As Usual ..
Lim Bio Liong wrote: Yes, it'd be great if there's an in-depth dissertation on ATL's IDispEventImpl. Especially one that can show how to use it in MFC apps. I'll see if I can get some time on this.
Thats would be Great ... if you find some time for that!
Lim Bio Liong wrote: But how about yourself, Alok ? Would very much like to see you contribute another winner !
Thats so nice of you, Sir!...But I am still in learning phase ... but as always its requires your help to get started ...
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Could someone tell me what I may be doing wrong with my rebar usage here. I have a multi-threaded SDI app with the auto-generated rebar in the frame window. I want to add a band with a generic window or dialog as its child window. So I have something like this in my frame window's OnCreate:
CMyRebarWindow rbw;
rbw.Create(m_hWnd);
AddSimpleReBarBand(rbw, _T("Title"));
rbw.Detach();
For the CMyRebarWindow class I've tried just basically empty derived classes from CWindowImpl<> and CDialogImpl<>. I get an access violation somewhere deep into the Win32 ::ShowWindow function call for the frame window, possibly related to the WM_SYNCPAINT message (I say this because every so often the debugger stops in a different place, somewhere in the handling of this message. If I replace the CMyRebarWindow with, for example, a CComboBox, everything is fine.
Are there some restrictions on the type of windows you can use within a rebar band? Any ideas what is causing this? I realise it may be something stupid since I've just started using WTL.
On a side note, can someone explain what happens with command and notification messages from controls in rebar bands - I noticed that with a CCombo box in there, the command messages that came through to the frame window, like CBN_SELENDOK for example, came not with the correct ID of the combo box, but with an ID of 1 for some reason.
Any help on any of this would be much appreciated. Thanks.
|
|
|
|
|
i am trying to access mehod of ocx but its showing runtime error
HRESULT hret;
try
{
CoInitialize(NULL); // init of Com
hret = testPtr.CreateInstance(__uuidof(TestOCX));
testPtr->Check(); //Crash here
}
catch( _com_error &e )
{
// Get info from _com_error
_bstr_t bstrSource(e.Source());
_bstr_t bstrDescription(e.Description());
TRACE( "\tCode = %08lx\n", e.Error());
TRACE( "\tCode meaning = %s\n", e.ErrorMessage());
TRACE( "\tSource = %s\n", (LPCTSTR) bstrSource);
TRACE( "\tDescription = %s\n", (LPCTSTR) bstrDescription);
}
catch(...)
{
TRACE( "*** Unhandled Exception ***" );
}
can anybody help me for the same
thanx
regards
Rajesh
|
|
|
|
|
|
Sounds like a bug in the OCX, it might be expecting you to call some initialization function first. 0x8000ffff is E_CATASTROPHIC, which is pretty much a catch-all for "something bad happened". Is this your own ocx? If it is, you should be able to step through it in the debugger. If not, I'd still run it in the debugger and look for first-chance exceptions, that would be a good indication of something wrong in the 'Check' method.
|
|
|
|
|
Hi,
we have created ATL dll in which we added one composite control on which
we have place an MFC user define control. we want to access the function of
that user define control.
we tried by getting reffrence pointer of that control but it gives memory
problem.
we are calling following stmt in OnInitDialog of composite control
CSOCX *cWnd = (CSOCX*)GetDlgItem(IDC_SOCXCTRL1);
if(cWnd)
{
cWnd->ShowWindow(SW_HIDE ); // it gives error here
cWnd->Assign(..);
...
}
please help me...
Regards
Rajesh
|
|
|
|
|
Dear friends,
Few days ago i developed an ActiveX control using MFC. The control was intened to be used by MFC dialog based clients. It is a windowless control. I preferred ActiveX control over simple COM dll, because it is easy to deal with the control events in MFC dialog based application. Just drop the control on the dialog, add a member variable, right click on it and handle events. So easy.
Now i want to use the functionality of this control in an application with no User Interface (i.e windows service). Is it possible to use the functionality exposed by ActiveX control in an application which provides no GUI container. If yes, then how ???
Ahsan
|
|
|
|
|
Is there any way to indicate the duplicate key insertion in STL map.
Here the key should be a class object.
|
|
|
|
|
#include < iostream >
#include < map >
using namespace std;
int main()
{
map < int, int > themap;
pair < map < int, int > ::iterator, bool > res = themap.insert(pair < int,int > (1,2));
if (res.second)
cout << "a value was inserted" << endl;
else
cout << "a value was updated" << endl;
res = themap.insert(pair < int,int > (1,3));
if (res.second)
cout << "a value was inserted" << endl;
else
cout << "a value was updated" << endl;
return 0;
}
If you have to be sure before inserting elements, you'll need to use find before inserting.
---
"Man will never be free until the last king is strangled with the entrails of the last priest". -- Denis Diderot
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
