In a C++/CLI DLL you can decide on class level whether you want to make it an unmanaged class (wich I think you mean with truly compiled) or a managed (.Net) class. You could create the business logic in unmanaged classes and provide a managed interface/wrapper for the VB.Net classes to call directly.
The good thing about pessimism is, that you are always either right or pleasently surprised.
cout<<"cout is executed"<<endl;
printf("printf executed \n");
//OutPut:printf is executed
// cout is executed
//Why printf is getting executed first??it output should be reverse right??
This is most probably a result of buffering of the output streams. I would bet that depending on the scenario/platform/compiler you could get different results with this very same code. Don't write such code or flush the streams if you want to guarantee write order.
If you're using a standard C++ compiler then the cout should happen first. However as you're not using a standard compiler (cout and printf are members of the std namespace for a standard compiler) then all bets are off. Get a new compiler and see if you have the same problem.
I have problems with 'WindowStateChange' events in my QWidget.
I have created a simple test widget with 3 buttons, to set window state:
and trace window state events (QEvent::WindowStateChange).
When I change 'normal' <-> 'max' there is no problem (altough i receive twice 'max' event), BUT when i change 'max' <-> 'fullscreen' i receive this events:
'max' --> 'fullscreen'
0 No State
state = windowState();
if ( state & Qt::WindowMaximized )
qDebug() << state << "Maximized";
So my widget has in both cases a strange flickering. That is, when 'max' --> 'fullscreen', it has an 'intermediate' "normal" state (0), and when 'fullscreen' --> 'max', it has several 'intermediate' states...
In my application, I must show/hide things when app is normal/maximized/fullScreened, so this flickering is really a problem.
Is it possible to do anything?
Thanks in advance,
Last Visit: 31-Dec-99 18:00 Last Update: 20-Dec-13 21:06