|
As always, the crowd cheers and roars at your upcoming tutorial  If you accept suggestions, there's an interesting subject in connection with namespaces that you might find worth writing about, namely the use of namespaces to support versioning: the library vendor just releases upgrades with different namespaces (say wonderlibrary1_0, wonderlibrary2_0, etc.) and the user decides the actual version she wants to use with
namespace wonderlibrary{
using namespace wonderlibrary2_5;
}Cute, isn't it.
Why do they want to do that ?
Don't know. I guess you can find explanations in comp.lang.c++.moderated. To be precise, the declaration has been annonunced from the latest 98 standard.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
there's an interesting subject in connection with namespaces that you might find worth writing about, namely the use of namespaces to support versioning
Hey - that *is* a cool idea. I will definately make mention of it.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"But there isn't a whole lot out there that pisses me off more than someone leaving my code looking like they leaned on the keyboard and prayed that it would compile.
- Jamie Hale, 17/4/2002
|
|
|
|
|
Simply, using the right header ( fstream, not fstream.h ) wraps all of the included stuff in namespace std, so including the right header would break your code in the 16 places you used fstream unless you also did a using std:: statement for each item you use from the header, or using namespace std;, which is evil and pointless, you may as well stick with the deprecated header if you do that.
Also, I forget - did you pass in a stream, or a *reference* to a stream ?
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"But there isn't a whole lot out there that pisses me off more than someone leaving my code looking like they leaned on the keyboard and prayed that it would compile.
- Jamie Hale, 17/4/2002
|
|
|
|
|
I passed it as a reference to a stream. Is that the problem?
Thanks for all the help.
-Raffi
|
|
|
|
|
Hey all,
I wrote a serial communications protocol stack (transport, network, and datalink layers) for on of our products as a standard library for use in Visual C++. Now of course they want me to convert it for use in Visual Basic  . My first thought was to convert it to an active X control, but the RX thread in the stack relies on a windows message. It didn't seem like MFC was going to make it easy to process this windows message and provide a control fire.
So I am thinking I can convert the static library to a dynamic link library and I was wondering if anyone had some quick tips on making this possible. This of course assumes that I can make VB handle windows message which probably won't work either  . I need to be able to export the CTransportLayer to VB which I think I know how to do.
I could rewrite everything exporting the right classes, but I want to make sure that I can maintain the code in one central code base. In other words I don't want to have to make changes in the static link library and also in the dynamic link library.
Thanks,
Brian
If you start a fire for a man, he will be warm for a day. If you start that same man on fire, he will be warm for the rest of his life.
|
|
|
|
|
well, you can't export any "classes" if you want to be able to use the DLL from VB because VB can only handle plain old C interfaced DLLs. and even then, you've got to be careful in your choice of parameters because VB is a little bitchy about dealing with pointers into structs and such.
for my projects, i write all the classes in C++ then put a plain C wrapper around them - then i export these C functions. if any C++ object needs to exist outside the library (ie. outside the C wrapper), i pass the object address out but i give it a "handle"-type name so that people won't be expecting to be poking around inside it. and, i put lots of validity checking when getting the object back (to make sure VB hasn't passed the wrong thing back).
-c
A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequilla.
Mitch Ratcliffe
|
|
|
|
|
If your code is mainly in classes, then I would create COM objects from them, and expose these objects through a typelibrary in your DLL. It may be a little bit of work to re-organize the code in this fashion, but this is the cleanest way to expose objects and functions for VB users.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
Yep my code is mainly in classes. Actually it is all in classes.
I guess though, I have created simple COM objects before, but I cannot find much information on typelibrary and how one creates these. Is there any references you can give me so I can check this out?
Also one of the things I don't want to do is maintain two different libraries. This shows my beginning nature in COM objects, but can I still use this as a static linked library, would I need to convert other projects, or maybe I should just create a COM object with a wrapper class around it that can be exposed?
Thanks for the suggestion, I would love to learn how to do this.
Brian
|
|
|
|
|
Does anybody know what happened to the GetFieldValue() method of the CRecordset class in MFC version 7?
In version 6, the method had 4 overloaded versions, one of which was:
void GetFieldValue( LPCTSTR lpszName, CString& strValue );
In version 7, the method still has 4 overloaded versions, but now the one stated above is missing, and seems to have been replaced with the following two:
void GetFieldValue( short nIndex, CStringA& strValue );
void GetFieldValue( short nIndex, CStringW& strValue );
The problem is that we have a bunch of code that uses the version that was only shipped in version 6, and hence the code does not compile in version 7 (without a bunch of tedious tweaking).
Was this an oversight by MS? Or did they have a reason for removing this particular version of the method?
Thanks in advance to all who have input 
--
Loren Brewer
|
|
|
|
|
I compile my old project to VC 7 and I can see dependency from oleacc.dll. This is accessibly controls, but I have not used this in my app. How to remove it?
Pavel Sokolov,
CEZEO software,
LanTalk Network,
http://www.cezeo.com
http://www.lantalk.net
|
|
|
|
|
This interesting Usenet thread treats the problem in detail. Esentially, this dependency breaks programs running in Win95 --Win98 and higher have the library by default (though it can be removed, which is another added problem). The simplest option is to statically link and activate delay loading, but a guy in the thread tells how to rebuild the MFC70 DLL so that it does not link oleacc.dll. Good luck.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I have a static control on my formview, it is linked with a control member m_static. I want to give this control a color background. So in
CMyView::OnDraw(CDC * pDC)
{
CBrush brush.CreateSolidBrush(RGB(255,255,255));
CRect rc;
m_static.GetClientRect(&rc);
ClientToScreen(&rc);
pDC->SelectObject(&brush);
pDC->Rectangle(&rc);
}
but instead of drawing a white rectangle, it is draw somewhere else on the screen. What did I do wrong? 
any hint is highly appreciated.
|
|
|
|
|
I'd say the (0,0) of the CDC passed to OnDraw is at the topleft corner of your drawing area, so ClientToScreen can be omitted.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Ok, here is what is going on
1. Your DC is relative to the origin of CMyView
2. When you invoke m_static.GetClientRect (), the rect is relative to the origin of the static control.
3. When you invoke ClientToScreen, the adjustments are being made to the CMyView window and not the static. Try m_static .ClientToScreen.
4. You also should add a call to ScreenToClient to move the screen rect for m_static to be coords relative to CMyView.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Finally, I got it. The code is like this:
RECT rc;
m_cStatic.GetClient(&rc);
m_cStatic.ClientToScreen(&rc);
ScreenToClient(&rc);
pDC->SelectStockObject(BLACK_BRUSH);
pDC->Rectangle(&rc);
But the problem is that: the black rectangle will not be displayed, unless I deselect the visible option of the static control. I tried use pDC->SetBkMode(OPAQUE) or TRANSPARENT, but it doesn't help. It seems to me that the static control hides the black rectangle. Why?
Tim Smith wrote:
Do I feel lucky?
Yeah, sure, I do feel lucky to have such a wonderful forum to go.
|
|
|
|
|
Tim Smith already answered your question; i'm just going to suggest that you use OnCtlColor() to change the background of the static control instead of doing it this way. You will more likely get the results you are looking for.
--------
Sip my mind.
|
|
|
|
|
Yeah, that was in the back of my mind too.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Got it. Overwriting OnCtlColor is cool and easy.
Thank you!
|
|
|
|
|
You are trying to draw this rectangle with the screen coordinates but in OnDraw() member function pDC->Rectangle(&rc) draws with client coordinates...
kozlu
|
|
|
|
|
Is there a way, a user can be prevented from re-sizing or moving a specific window. In this case, the window is a CFrameWnd derived object.
Thomas
modified 29-Aug-18 21:01pm.
|
|
|
|
|
|
The easiest way to prevent a window from being sized is to remove the WS_THICKFRAME style from the frame window and replace it with a WS_BORDER style.
The easiest way to prevent a window from being moved is to handle the WM_NCHITTEST message, and convert all HT_CAPTION styles that are returned by DefWindowProc to HT_BORDER. Windows only allows the window to be moved when the cursor is selected over a caption region. The inverse of this, if you make all HT_CLIENT results return a HT_CAPTION instead, the user can move the window whenever they click inside any portion of the window, not jsut the caption.
For finer control in what you do, you can override the WM_ENTERSIZEMOVE message, and filter off any processing for sizing or moving before it even starts. That way a user cannot start dragging the window, you nip it in the bud.
If you were to override the WM_SIZE message, the window would be resized, then it would snap back into place after you handled the message.
Good luck
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
In the case of SDI MFC project, how could I remove the WS_THICKFRAME style?
|
|
|
|
|
lucy wrote:
In the case of SDI MFC project, how could I remove the WS_THICKFRAME style?
Override PreCreateWindow
Nish
The rumours that I am an AI bot are absolutely false. These rumours have been propogated by *them* to focus all the attention on to me, while *their* bots take over the planet. Thank y%%%% Divide by zero. Cannot proceed. Abort(y/y)?
|
|
|
|
|
For prevent re-sizing:
BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs)
{
if( !CFrameWnd::PreCreateWindow(cs) )
return FALSE;
// TODO: Modify the Window class or styles here by modifying
// the CREATESTRUCT cs
cs.style = WS_DLGFRAME ;
return TRUE;
}
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
