|
Hi Christian,
Sorry if this sounds like a really stupid question, but do you mean exported COM methods? Have you deleted them from the IDL and renumbered all of your IDL functions? For example:
[id(1), helpstring("method ExecuteSql")] HRESULT ExecuteSql([in] VARIANT avCommand, [out] VARIANT *apvResponse);
[id(2), helpstring("method ExecuteDml")] HRESULT ExecuteDml([in] VARIANT avCommand, [out] VARIANT *apvResponse);
[id(3), helpstring("method GetStatus")] HRESULT GetStatus([out] long *aplStatus);
Then, trying to delete ExecuteDML, you would need:
[id(1), helpstring("method ExecuteSql")] HRESULT ExecuteSql([in] VARIANT avCommand, [out] VARIANT *apvResponse);
[id(2), helpstring("method GetStatus")] HRESULT GetStatus([out] long *aplStatus);
remembering to renumber the method to 2. All of this is in addition to removing the functions from the .h and .cpp files associated with the IDL.
Again, sorry if this seems obvious, but my experience has always shown that it's the obvious things you miss... Hope this helps.
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
To be honest, it's my recollection that I expected to have to do that but couldn't find where it was. I also deleted the weird lookin' stuff that was associated with my function and looked to me like it was specifying offsets in memory for functions & variables, is that right ?
Thanks for the help.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Yeah, the IDL is contained in the <interface name="">.dil file in your interface definition. Having a quick look at the example project I was using, the only line I would have removed from the <interface name="">.h file was:
STDMETHOD(ExecuteDml)( VARIANT avCommand, VARIANT *apvResponse);
and also the corresponding implementation in <interface name="">.cpp. I think that's about it. You will, though, have to make sure that the MIDL compiler regenerates the main project .h file which contains the stubs that wrap around the COM calls. If you've screwed around with this file, I'd try deleting it, modifying your IDL so the MIDL compiler fires off again and regenerating.
The id numbers in the IDL specify the function offsets in the COM object. These definitely have to be sequentially increasing. Any missing or mis-ordered numbers cause things to go very askew (as I've found out from experience).
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Ah.... *light comes on* So if I remove the .h and .cpp references to the fucntion, and the IDL reference which has the number, the compiler will fix the rest ?
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
Yep. At least, that is my belief, without wanting to 100%, no doubt, absolutely stake my life on the behaviour of Visual C++...
------------------------
Derek Waters
derek@lj-oz.com
|
|
|
|
|
Thanks for the help - I'll backup my project tonight and give that a try.
Christian
As I learn the innermost secrets of the around me, they reward me in many ways to keep quiet.
Men with pierced ears are better prepared for marriage. They've experienced pain and bought Jewellery.
|
|
|
|
|
(1) Remove the function declaration from the IDL file
(2) Remove the function declaration from the implementation class
(3) Remove the function implementation from the implementation class
(4) Rebuild the project
Mohamed Mabrouk
|
|
|
|
|
hi everyone,
I want my CEdit to scroll to the bottom after a call to SetWindowText. The following code updates the scroll bar, so it looks like it's at the bottom, but the edit actually remains unscrolled:
int max = m_edit.GetScrollLimit(SB_VERT);
m_edit.SetScrollPos(SB_VERT, max, TRUE);
I had the same results with GetScrollRange. What is the right way to scroll the edit?
thanks,
Jake
*****
Jake Palmer
www.duke.edu/~jp6
|
|
|
|
|
Hi,
I used this function in a CEdit-derived class:
void CChatEdit::AddString(LPCTSTR str)
{
CString tmp;
GetWindowText(tmp);
if (!tmp.IsEmpty())
tmp += "\r\n";
tmp += str;
SetWindowText(tmp);
LineScroll(GetLineCount());
}
To add a line of text and scroll to the bottom.
I hope it works for you too  (you never know)
Paolo
------
"airplane is cool, but space shuttle is even better" (J. Kaczorowski)
|
|
|
|
|
Netmeisters,
I am relatively new to Windows programming, so my
apologies if the following problem has an obvious solution.
I would like to use a CEdit control in a CDialog as a log,
recording events that occur during a syncing process over
a network. (As it happens this is for a Pocket PC but I
think the question applies equally to all forms of
Windows). The syncing process should start automatically
as soon as the CDialog is opened, and lines are added to
the CEdit to describe the progress of the sync. Currently
the sync process is invoked by a message handler that
responds to the WM_INITDIALOG message. The problem with
this is that the whole log gets written (ie the CEdit is
completely filled) before the CDialog is displayed, so
that the user gets a log, but can only see it after the
sync is completely done (whereas I'd like him to be able
to follow the sync as it occurs).
My question is, is there another message I could use,
which gets triggered AFTER the CDialog is displayed,
rather than just before? Then all I would have to do is
invoke my sync in a message handler responding to this
message, rather than WM_INITDIALOG.
The only other approach I can think of would require the
creation of a second thread, and I've got to think there
is an easier way.
Your assistance much appreciated,
Matthew Fleming
mgf@mcw.edu
|
|
|
|
|
Hi,
A simple solution could be posting a custom message to the dialog, and starting the syncing process in response to that message instead of WM_INITDIALOG.
Something like:
#define WMU_STARTSYNC (WM_USER+123) // or register one with RegisterWindowMessage()
CMyDialog::OnInitDialog()
{
PostMessage(WMU_STARTSYNC);
...
}
CMyDialog::OnStartSync()
{
...
}
Posted message will be handled after all the messages in the queue get handled, so hopefully after the dialog is displayed (surely after WM_INITDIALOG).
You may also force the dialog to be visible with ShowWindow(SW_SHOW) in OnInitDialog(), but the dialog won't be centered (try CenterWindow() to fix that).
Cheers,
Paolo
------
"airplane is cool, but space shuttle is even better" (J. Kaczorowski)
|
|
|
|
|
Hi,
Does anybody have some C routines for converting 32- and 64-bit IEEE 754 numbers to strings?
Thanks!
Erik
|
|
|
|
|
_gcvt() should do the trick (at least for 32-bit numbers)
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Has anyone had a look at Maarten Hoeben's List Control. I've got it working, in both a Dialog, and a Child Window in the MDI app, but, I cannot gee the preview feature to work in the MDI window. Any ideas on what is different from the Dialog example given.
http://www.codeproject.com/miscctrl/reportctrl.asp
Thanks,
Giles
|
|
|
|
|
This service is required to listen on a port for incoming requests from
various clients. My programming experience with sockets is centered around
the MFC CSocket class. It appears after several hours of tests that CSocket
is not supported in an NT Service (or I need to jump through some hoops I have not found yet).
Any Assistance would be appreciated
mantrashrim
|
|
|
|
|
Just off the top of my head, MFC and services are not a recommended mix, but I _think_ there is information in an article by P.J. Naughter dealing with creating a service using MFC - not sure if its in with the stuff on site, or if it targets your issue, but maybe a useful read.
As for CSocket/service incompatibility, not sure... I'd think you could at least put the CSocket stuff off in a DLL - if there's docs on this problem I'd like to see 'em.
|
|
|
|
|
As you guessed, CSocket does not work with Services because of the way it is tied into the MFC event hadling system.
As Tim said, PJ Naughter has a CScocket class which does work, as well as that he has also derived a number of other protocols from it such as SMTP, POP3 etc to be used from an MFC app or a Service.
I recommend looking at Programming Server Side Applications for Windows 200- by Jeffery Richter. All about Services, and things like IO Completion prots to make apps handle large loads with ease.
Giles
|
|
|
|
|
I recommend looking at Programming Server Side Applications for Windows 200- by Jeffery Richter. All about Services, and things like IO Completion prots to make apps handle large loads with ease.
Yea, it's a great book. But when programming socket, I like "Network Programming for Microsoft Windows" even more...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Hi Anders,
Yep, got a copy of that as well. Great book, with loads of detail. I did not want to start thowing the library at him though. I must say that the MS Press books are really well written, and well produced. I have never been disapointed with any of those I have bought.
I've been experimenting with PERL over the past couple of months, and was on a 4 day course for it last week. It was great to be able to write an Echo server in 3 lines. Made me laugh. I'm now a convert after being a sceptic.
It made me think, C++ for the performace stuff, and PERL for every thing else. Its made me realise that despite JAVA being a modern langugae, it is such a pile of s$@t!
Giles
|
|
|
|
|
I am not answering your question regarding CSocket. I am not familiar with CSocket - so I do not know. But, I have written many services with socket support.
The best mechanism is to use the IOCompletion port. There is an article titled "Writing scalable servers using IOCompletionport". This demonstrates a server with a Win32 console application. It should be fairly easy for you to convert this into a service.
- Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Thanks to all of your for your responses... I will be picking up the books mentioned....
speak to you all soon
mantrashrim
|
|
|
|
|
I am using Alt+F1 as a hotkey to bring up a dialog box. The problem that I am facing is that many times the new dialog that comes up gets the "Alt" and the focus is on the system menu of the window. Is there any way, I can avoid this problem? The hotkey is configurable, so not using 'Alt' is not an option in this case.
-Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
Hey hey hey! I'm trying to run the function BringWindowToTop. Finding that it's not working the way I intended.
I have this function in the Update method within the View Class. I call it from the MainFrame class.
Here's the setup. I have a file list view docked in the main application window that a user can click on existing opened files. They click on a file and the window should come to front. I am finding the right document and calling the proper View class from the document, however it seems the BringWindowToFront is not Brining the Window To the Top. (sorry)
Might there be more that one needs to do in order to successfully get the effect I'm looking for?
Thanks!
"Why are we hiding from the police, Daddy?"
"We use VI, son. They use Emacs."
|
|
|
|
|
Hi,
A View window is a child window of its parent frame. I think you should call BringWindowToTop to the frame, not the view.
Something like:
wndMyView->GetParent()->BringWindowToTop();
Not sure, however.
Paolo
------
"airplane is cool, but space shuttle is even better" (J. Kaczorowski)
|
|
|
|
|
I found my older code on this where I write
GetParentFrame()->BringWindowToTop();
I knew I wrote this sometime. =)
Thanks for the help though!
Chris
"Why are we hiding from the police, Daddy?"
"We use VI, son. They use Emacs."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
