|
Can you create a clock by ActiveX control using ATL
|
|
|
|
|
|
Hi J.Sigvardsson
Thank you very much
|
|
|
|
|
Hi,
I have some troubles to add an enumeration to an existing idl-file. (VC++ 6.0, ATL-EXE-Project)
I am declaring the enumeration like this:
import "ocidl.idl";
[
object,
uuid( C15A95C3-1437-4ec4-B290-1B73573F4007),
// AT 11.08.2005 dual,
helpstring("ISEPSJobManager Interface"),
pointer_default(unique),
// AT 11.08.2005 oleautomation // AT 11.07.2004
]
interface IJobManager : IUnknown
{
typedef enum tag_SEPSSensorStatus{
eSeps_Sensor_OK,
eSeps_Sensor_ALARM
} eSEPSSensorStatusID;
--> I could declare 3 types of enumetations some years ago, but now when I am adding a new enumeration I can't use it from my client.
I have checked the following issues:
- Adding a new method to the interface works fine.
- Adding a new enumeration adds the enumeration to the header-file of my ATl-Project, but does not add the enumeration to the *.tlh-file of the client, neither I can observe a change in the OleView.
Does anybody know what causes this behaviour or how to implement a workaraound?
Is it possible, that the previous definitions
' dual' or 'oleautomation' causes the problems.
Thanks in advance
andi
|
|
|
|
|
As per ur code it seesm u declared the enum in interface defenition. Thats wrong u have to declare it outside the interface defenition. Other than that there is nothing wrong in your code. Also its a gud practice to have a uuid associated with ur enum. see the code below.
typedef [uuid(85916817-EE0E-4f0d-B7DB-FE6F15890CB5)]<br />
enum _eSEPSSensorStatusID{<br />
eSeps_Sensor_OK,<br />
eSeps_Sensor_ALARM<br />
} eSEPSSensorStatusID;
rgds ...mil10
|
|
|
|
|
thank you for this proposal.
I tried to add this to my idl-file, but it didn't solve my problem. -> now I am following the advice of Vita (to reference the enumeration in the library).
Thank you for answering my question
tagi
|
|
|
|
|
You should never ever add new/modify/remove methods to/in/from an interface, nor should you ever change enumerations after they've been published. COM isn't robust enough for that.
What you can do is to add a new interface which can handle the "new" way of doing things. With it, you should also declare the new enumeration.
Good music: In my rosary[^]
|
|
|
|
|
thank you,
of course you are right. you should never change an existing interface. But since I havn't released my project yet and I am fully aware of all the clients using the server I didn't want to create a new Interface.
thank you for answering
tagi
|
|
|
|
|
tagi1 wrote:
- Adding a new enumeration adds the enumeration to the header-file of my ATl-Project, but does not add the enumeration to the *.tlh-file of the client, neither I can observe a change in the OleView.
Does anybody know what causes this behaviour or how to implement a workaraound?
The TLB contains only those types which are defined or mentioned (directly or indirectly) inside [library] block in IDL file.
So inside [library] block there should be something which refers to SensorStatus enumeration.
With best wishes,
Vita
|
|
|
|
|
Thank you for this advice. I didn't know that I have to use an enumeration which I have declared in the idl-file.
Now its working.
best regards
tagi
|
|
|
|
|
Hi,
I'm sure this is probably the easiest question in the world but I can seem to find anything anywhere about how to do it. Basically I have created a dialog in an MFC program, but it is a fixed size, I want the user to be able to resize it, how do I do this?
Cheers
|
|
|
|
|
In the resource editor, open the properties for your dialog and select the Border style to be "Resizing". You will then need to handle the WM_SIZE message in your dialog's code (use ClassWizard) so that you can handle the resizing/repositioning of any child controls when the dialog is resized. This is a pretty common problem when using dialogs under MFC and there are a boatload of solutions, many of them on here. I recommend searching for Paolo Messina's dialog resizing solution which works nicely.
Hope that helps...
|
|
|
|
|
Thanks alot for that, knew it had to be something faily simple, that sorted it staight away. Cheers for help, much appreciated! 
|
|
|
|
|
This might prove useful:
http://www.codeproject.com/dialog/dlgresizearticle.asp
It'll save you the trouble of manually repositioning controls in response to WM_SIZE messages.
HTH
|
|
|
|
|
Hi.
I'd like to change dialog's class name from "#32770" to "MY DIALGO".
I used following code in WTL. But it doesn't work
WNDCLASSEX wndClass;
::GetClassInfoEx((HINSTANCE)_Module.GetModuleInstance(), "#32770", &wndClass);
wndClass.lpszClassName = _T("MY DIALOG");
::RegisterClassEx(&wndClass);
would somebody gave me a solution?
Thanks. Have a good day....
|
|
|
|
|
Have a look at the DECLARE_WND_CLASS() macro
|
|
|
|
|
Hi,
I am creating an com addin for Office using VC++. The project is ATL based. My question is how can I implement a common handler for a set of CommandBarButtons?
Thanks in advance
Akshay
|
|
|
|
|
AkshayO wrote: I am creating an com addin for Office using VC++. The project is ATL based. My question is how can I implement a common handler for a set of CommandBarButtons?
The sink map basically provides the mapping between a dispid that defines the event and the member function that handles it. Command button fires the event with dispid 0x01 so there is no need to setup sink map for every button.
BEGIN_SINK_MAP(CAddin)
SINK_ENTRY_INFO( 1,__uuidof(Office::_CommandBarButtonEvents), 0x01,OnClickButton,&OnClickButtonInfo)
END_SINK_MAP() You can differentiate button's with the help of button value or caption.
void __stdcall CAddin::OnClickButton(
IDispatch* Ctrl,
VARIANT_BOOL * CancelDefault)
{
USES_CONVERSION;
CComQIPtr pCommandBarButton(Ctrl);
MessageBox(NULL, "Clicked", "OnClickButton", MB_OK);
}
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
Hi
why compile this method occurs warning!
can the warnnings be disapper?
template<class T><br />
void Fun()<br />
{<br />
vector<T> vecTest;<br />
vector<T>::iterator iter = vecTest.begin(); <br />
}
main.cpp: In function `void Fun()':
main.cpp:10: warning: `typename std::vector<t, std::allocator<_chart="">
>::iterator' is implicitly a typename
main.cpp:10: warning: implicit typename is deprecated, please see the
documentation for details
please help me
I love Programming
|
|
|
|
|
my compiler is gcc
I love Programming
|
|
|
|
|
If you were to check 'Do not treat <'s as HTML tags', your message would be readable 
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
You need to write:
<code><font size=2 face="Courier New"><font color="#000080">template</font><<font color="#000080">class</font><font color="#008080"> </font>T>
<font color="#000080">void</font><font color="#008080"> </font>Fun()
{
<font color="#008080"> </font>vector<T><font color="#008080"> </font>vecTest;
<font color="#008080"> </font><font color="#000080">typename</font><font color="#008080"> </font>vector<T>::iterator<font color="#008080"> </font>iter<font color="#008080"> </font>=<font color="#008080"> </font>vecTest.begin();
}
</font>
</code>
See also: C++ Templates FAQ[^]
|
|
|
|
|
Hello folks,
I have been trying to pass array of string from my ATL component (I'm using VC++ 6) to VB.
Basically I have a vector of strings in my ATL component which I need to pass to VB.
I have been reading and confused about using either VARIANT *Array or SAFEARRAY *Array in my IDL declaration. Are they the same?
Anyway would somebody gave me an example on how to do this as well as the calling sample from VB code?
Thanks in advance
|
|
|
|
|
A SAFEARRAY is one of the things a VARIANT can contain.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
bluish wrote:
I have been reading and confused about using either VARIANT *Array or SAFEARRAY *Array in my IDL declaration. Are they the same?
No they are not the same. As Christian says, a SAFEARRAY is one type which a VARIANT may be. The reason for the confusion is because lesser languages such as VBScript don't know how to handle SAFARRAYs in the interface declarations - it can only handle VARIANTs. That's why SAFEARRAYs are passed as VARIANTs.
It's odd. VBScript knows how to deal with SAFEARRAYs internally, but it doesn't understand it in interface declarations.
--
An eye for an eye will only make the world blind.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
