|
Hey, I've created an ATL object in a .dll, and i am trying to call the function dynamically. How do i need to setup my functions to get them to not give back crappy values (my BSTR="?????????????????????????????")
i tried __stdcall or _export but nothing is working. i also have "ByVal" for the parameter in my function definition in the VB section.
~Timothy T. Rymer
www.digipen.edu
tim.xpertz.com
|
|
|
|
|
Is the ATL object a COM object, if so then you simply need to declare your class inside of the type library that is created in your idl file of your project.
Then you can go to the Project | references menu item in your VB project in order to reference your COM object. From there you can use that object in VB just like any other object.
If you are actually exporting an object like you say rather than a function, you would need to instantiate an instance of this object before it can be used, and I do not know of a way to use a C++ object in VB except through COM. If this is what is happening, I am surprised that your program is not crashing.
|
|
|
|
|
Hi,
I have a CListBox derived class. I created a context menu which sends a WM_COPY message. I handle this message and copy stuff to clipboard, works fine.
How can I add a CTRL+C key functionality to my class? Pointing me to the right direction would be fine! Well, do I need to create this WM_COPY message by myself (via PreTranslateMessage()) or do I request it somehow?
Thx, Moak
PS: Btw, what is the difference between using ON_MESSAGE() macro or ON_COMMAND() in the MESSAGE_MAP?
|
|
|
|
|
This can be done with a type of resources called accelerators. Go to the resource editor and create a new "Accelerator" object. From here on everything should be clear enough.
As for the difference between ON_MESSAGE and ON_COMMAND , the latter is provided to deal with the special message WM_COMMAND , which can be regarded as comprising many "submessages" (one for each command identifier).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thx, will do!
I just wonder that my CEdit control gets a WM_COPY message, while my CListBox does not (I used the C++ spy to trace messages). Well, is there something special on a edit control that it gets a WM_COPY "for free"? I would like to generate those standard "accelerators" dynamically... I mean when I use a instance of my CListBox class it should automatically handle CTRL+C and not rely on a manual resource entry. Comfort is what I seek.
Greets, Moak
|
|
|
|
|
I would like to generate those standard "accelerators" dynamically...
I see. Well, then maybe accelerators are not the best solution. Another solution that does not require the user of your class to do any extra work is: handle WM_KEYDOWN , check for the CTRL+C code and send the WM_COPY command when appropriate.
As for the code for CTRL-C, I don't know it right off the top of my hat, but you can just write some OutputDebugString or something in your OnKeyDown to find it out.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
yep, it works.
BOOL CListBoxChat::PreTranslateMessage(MSG* pMsg)
{
if(pMsg->message == WM_KEYDOWN)
{
TRACE("[LBC] DEBUG WM_KEYDOWN %d\n", pMsg->wParam);
switch(pMsg->wParam)
{
case 'C':
case VK_INSERT:
if(GetKeyState(VK_CONTROL))
return SendMessage(WM_COPY);
break;
}
}
return CListBox::PreTranslateMessage(pMsg);
}
|
|
|
|
|
Congratulations! Good luck with your project.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have a question of about the use of a system timer within a class. The class
in question is a dialog control class derived from CEdit. What I need to know
is when is the appropriate time to allocate and setup the timer via the call
to SetTimer(). I also need to know when is the appropriate time when to quit the
timer service via the call to KillTimer(). My initial thought was as follows:
Call SetTimer() within my class constructor;
Call KillTimer() within my class destructor;
However I have been thinking if it would be better to add event routines to my
class to support the WM_CREATE and WM_DESTROY and place the calls as follows:
Call SetTimer() within my class OnCreate() event handler;
Call KillTimer() within my class OnDestroy() event handler;
For any of you out there that are more experienced than myself I would ask....
Which of these approaches is better or more apt to work better? And if these
are neither appropriate then what is the proper implementation?
Thank you,
Mike
|
|
|
|
|
Call SetTimer in CYourEdit::OnCreate . Kill the timer in CYourEdit::OnDestroy (or alternatively, let the timer be killed by the system upon window destruction).
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
|
Thankyou All that replied on the Timer issue. And thx esp to Nemanja for the link to the timers article.
Mike
|
|
|
|
|
WM_CREATRE and WM_DESTROY are good place
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
I'm stuck. I have MFC-based application, which has in itself CHtmlView. I'd like to have var list in JScript in the current page.
Or maybe somebody know the way to write own JScript debuger?
Thnx in advance,
Sergey
|
|
|
|
|
I am making a regular DLL, and want it to be situated in the windows folder, so each program i make that is installed does not need a seperate copy, but do not know how to do that.
Can someone help?
==================================================
When Your Mind Wonders...Where Does It Go???
|
|
|
|
|
If you're using some installation progfam to do your install package, then there will be means there to indicate that a certain DLL must be located in the system folder.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I seem to remember looking at some code tht had a function to do with registering, so i thought you needed to add some code into the DLL.
==================================================
When Your Mind Wonders...Where Does It Go???
|
|
|
|
|
If you use ATL wizard to write dll,it add those function for you,you only add dll to installshield and check it as selfregister in installshield wizard and installshield do another things for you
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
run this on command:
regsvr32 pathoffile
also if you compile your dll project it is self register and it will register automaticlly
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
Maybe this term 'regular DLL' confused me, but I don't believe he is developing a COM server. Therefore, he does not need to register anything.
I vote pro drink
|
|
|
|
|
Yeah
He simply needs to copy it to the system folder within the windows folder
Nish
Nish was here, now Nish has gone;
He left his soul, to turn you on;
Those who knew Nish, knew him well;
Those who didn't, can go to hell.
I like to on the Code Project
Sonork ID 100.9786 voidmain
www.busterboy.org
|
|
|
|
|
yaep,it seems you're right
Mazy
Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without
|
|
|
|
|
Hi,
i have a window, simply created with the Win32 API (RegisterWindowEx and CreateWindowEx) no MFC.
I use my own WindowProc (...), and return DefWindowProc to process the messages i don't process myself.... a classic.
I processed the WM_SIZE and WM_MOVE messages up to now without problems, but i have added the processing of the WM_WINDOWPOSCHANGED in my window proc, and i don't receive WM_SIZE and WM_MOVE messages anymore.
Looking at the VC6 docs for WINDOWPOSCHANGED, they briefly say that when DefWindowProc() processes WINDOWPOSCHANGED, it sends the WM_MOVE and WM_SIZE messages to the window.
Then, now i process WINDOWPOSCHANGED myself, that seems to be logic that i don't receive WM_MOVE and WM_SIZE anymore.
Here is my question,
are the WM_MOVE and WM_SIZE messages sent EXCLUSIVELY by DefWindowProc() or does the system(framework) sends these messages to my window too ?
If the system sends them too, could you please tell me when it does so ?
Cheers,
Lion.
|
|
|
|
|
MSDN article Size and Position Messages seems to imply that WM_SIZE and WM_MOVE are only sent from DefWindowProc . Quote:
A window that must process WM_SIZE and WM_MOVE messages must pass WM_WINDOWPOSCHANGED to the DefWindowProc function; otherwise, the system does not send WM_SIZE and WM_MOVE messages to the window.
There could be room for interpretation, but IMHO this paragraph seems to be a little more conclusive with respect to this issue than the documentation on WM_WINDOWPOSCHANGED .
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks,
this is exactly what i needed to know because it isn't explicitly writen in my docs.
Lion.
|
|
|
|