|
I know exactly what you mean, the same ting happens if you make a spelling error in a function name, and try ro rename the function 
I have done it by doing a search/replace in all the files in the project, and then rebuilt the project...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
The problem seems to be that while that would work for a rename, if you go through and *delete* a function, because of the way it's all laid out, any functions you add after it won't get found in the vtable, so I end up with NULL pointers when trying to create them.
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.
|
|
|
|
|
Wow, I have been working with ATL for 4+ years and have never had any problem like that. Well, other than sometimes the compiler not rebuilding everything. Rebuild all fixes that.
I did have one problem one time, but it turned out that I named an H file with the same name as a system file (i.e. version.h), thus the compiler would always ignore changes to that file as far as requiring rebuilds.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
I did have one problem one time, but it turned out that I named an H file with the same name as a system file (i.e. version.h), thus the compiler would always ignore changes to that file as far as requiring rebuilds.
Sounds like the debugging problem from hell !!
I've got a feeling when I go through and delete every piece of code with the name of my function, some of the funky looking stuff I delete should be left or changed, I'm just not sure what.
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.
|
|
|
|
|
Is this in conjunction with the class wizard?
If so, that could explain why I have never seen any type of problem like that. I have always been too bullheaded and lazy to learn those classwizards.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
The classwizard does not support removing functions, although I used it to add them ( well it's not the classwizard, but I assume you mean the class view ).
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, that is what I ment.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
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!"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
