C / C++ / MFC

Automatically Minimizing Window

4-Apr-02 13:42

1) If you don't need to modify the char array, you can simply cast a CString to an LPCTSTR (long? pointer const TCHAR string):

LPCTSTR apszBuffer = (LPCTSTR)m_MyCstring;

If you need to modify the buffer, you need to use GetBuffer and ReleaseBuffer:

LPTSTR apszMyBuffer = m_MyCString.GetBuffer(m_MyCString.GetLength());
// Do something with apszMyBuffer, changing its length to 25
m_MyCString.ReleaseBuffer(25);

2) Use atoi, atof (or _ttoi for wide-char compatibility):

int viValue = atoi("25478");
float vfValue = atof("123.456");

3) Use CString::Mid():

CString vstrBit = m_MyCString.Mid(0, 2); // First two chars
CString vstrAnother = m_MyCString.Mid(5, 4); // Chars 5-8

Hope this helps.

------------------------
Derek Waters
derek@lj-oz.com

4-Apr-02 13:23

Hello. I'm just starting out in VC 6.0. I'm using MFC Appwizard, and have created a test program. I've got it so far where you click on a button and a MessageBox pops up. I was wondering, I want to add some code in there that will automatically Minimize the current window. So, you'll click on my "test" button, and it will automatically minimize the window. Can anyone please point me in the correct direction?

Re: Automatically Minimizing Window

Derek Waters4-Apr-02 13:37

Re: Automatically Minimizing Window

4-Apr-02 13:37

Yep:

CMyDialog::OnTestBtn()
{
  ShowWindow(SW_MINIMIZE);
}

Hope this helps.

------------------------
Derek Waters
derek@lj-oz.com

moredip4-Apr-02 13:31

Urgent: ActiveX and repaint issues.

4-Apr-02 13:31

First off you might want to use AfxGetMainWnd(), which returns a pointer to the main application window.

You could then use CWnd::ShowWindow( SW_MINIMIZE ) to minimize it. So all together you've got:

CWnd *pMainWnd;

pMainWnd = AfxGetMainWnd();
pMainWnd->ShowWindow( SW_MINIMIZE );

Tada!

Hope that helps,

Pete

Oz Ben Eliezer4-Apr-02 13:23

Oz Ben Eliezer

4-Apr-02 13:23

Hey all!

I'm semi-desperate.
I developed an ActiveX control that runs within IE, using ATL.
In it, I use owner-drawn controls and common controls (listview, tabbed control).

Sometimes (more often on win98 than on win2k / xp), when a dialog (generated by the ActiveX or by another application) covers part of the ActiveX, and then is removed (closed, not dragged away) - some (or all) of the area that was previously covered is not repainted.

This behavior startled me - so I decided to use remote debugging, to hunt down the WM_PAINT and related messages. I was able to recreate a procedure during which a dialog covered part of the ActiveX - and when I removed it - one of the owner-drawn buttons was not repainted (a grey rectangle appeared instead of the button's image).

I put a breakpoint inside ATL's ProcessWindowMessage (the function that is inserted by the BEGIN_MSG_MAP(<class name="">) macro).

After dismissing the dialog - NO MESSAGES WHATSOEVER were sent to the application!

I also noticed that sometimes when a convering window is closed and the ActiveX seems to be properly repainted - no messages are received (as if Windows "remembered" the content of the control).

Sometimes even tooltips leave a grey rectangle behind them when they disappear! (this happens a lot in Win98).

The ActiveX control has its own HWND.

Im not sure I fully understand the way the ActiveX control receives messages. Does its window receives messages directly from Windows, or do messages somehow pass through IE?

And at any case - can anyone offer a solution to this problem? (or at least give me a lead...)

Thanks a lot in advance!
Oz

Re: Urgent: ActiveX and repaint issues.

Douglas Troy5-Apr-02 4:33

Douglas Troy

5-Apr-02 4:33

Hey,

you may already have the answer to your question, but if you don't I might be able to point you in the right direction. I recently dealt with a host of ActiveX issues myself, and I recalled reading that messages are dispatched to the container class, and you are responsible for getting those messages, and passing them through to your control.

Check out the MSDN Topic "Active Technology" and go from there, I beleive you'll find at least an example of how messages are passed to the control.

In terms of Win98 Repaint messages not being sent, don't know about that, but I would install the latest Service Pack and the latest Video Card drives on that machine before I started pulling my hair out.

D.

DLL mandatory with EXE

4-Apr-02 12:16

Hi everyone,

Maybe a stupid question but I have to ask...
When we create a EXE and give it to somebody else, there`s is an error about some missing DLLs.

I think it`s related to VC++ since they don`t have that application on their computer. Is there a way to know which DLL I have to pack with the EXE ? (Please, don`t tell me to try it on an other computer and write down the names of the DLLs that are missing Dead | X|

)...

Also, by default, when we create a project (like win32 application), is there a difference between debug and release configuration ? Like is the debug configuration requires those DLL and release doesn`t ? Thk in advance !

Tim Smith4-Apr-02 12:29

Tim Smith

4-Apr-02 12:29

You can avoid this problem by linking statically instead of dynamically.

Release mode builds the program without debug information and with optimizations.

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?

Frederic Filiatrault4-Apr-02 12:38

Frederic Filiatrault

4-Apr-02 12:38

Thk for the answer...
And where do I go to link statically instead of dynamically ? Blush | :O

F. Filiatrault

Derek Waters4-Apr-02 12:39

4-Apr-02 12:39

You can find out what DLLs your program requires by running the Dependency Walker (depends.exe) that comes with VC++.

The difference between debug and release builds is that debug builds use MFC42D.DLL and MSVCRTD.DLL instead of MFC42.DLL and MSVCRT.DLL (no D's). The debug versions of these are not redistributable, so you should only distribute Release versions of your software. As described in the earlier post, linking statically removes the hassle of having to distribute these DLLs with your program, however, you may need others that depends.exe will show you.

------------------------
Derek Waters
derek@lj-oz.com

Frederic Filiatrault4-Apr-02 12:52

Frederic Filiatrault

4-Apr-02 12:52

Hi again,

thk for the answer. With DEPENDS.EXE, it shows KERNEL32.DLL & NTDLL.DLL. I don`t think I have to include those files. So, here`s two other questions :

1) How can I know which one of those DLL other users have

2) I have WinXP, what happen if I want to give my EXE to someone with a older OS version like Win98 ?

thk in advance !

F. Filiatrault

Derek Waters4-Apr-02 12:57

4-Apr-02 12:57

Frederic Filiatrault wrote:
1) How can I know which one of those DLL other users have

Well, the simple answer is that you need to find the corresponding DLL on their system. Usually they will be in the C:\Winnt\System32\ or C:\windows\system\ folder.

2) I have WinXP, what happen if I want to give my EXE to someone with a older OS version like Win98 ?

This one is down to your installer. As long as you are not relying on newer functions in these DLLs (MSDN help tells you which versions of DLLs each API call resides in) then you should be OK. Your program's installer should, in theory, include the versions of each DLL that your program relies on, and should check to see whether the user's version of the DLL is newer. If the user's current version is older, then you can copy (and register, if necessary) your copy of the DLL. You can also find out what versions of Windows DLLs are installed by what products by looking at the Microsoft DLL database at:

http://support.microsoft.com/servicedesks/fileversion/dllinfo.asp?fr=0&sd=msdn

Hope this helps.

------------------------
Derek Waters
derek@lj-oz.com

Oz Ben Eliezer4-Apr-02 13:23

Oz Ben Eliezer

4-Apr-02 13:23

Hey,

I have a related question.
How do you deal with Unicode issues?
I think (am I wrong?) that some system (or at least Microsoft) DLLs come in two flavors - Unicode and ANSI. Suppose that my application is compiled as an ANSI application, and I want to distribute it with a set of compatible DLLs - how do I avoid overwriting ANSI versions of DLLs with Unicode versions, and vice versa?
Also - where can I find the redistributable DLLs? (MS surely doesn't expect me to copy them from my HD, do they?)

Thanks!

Derek Waters4-Apr-02 13:32

4-Apr-02 13:32

Yep, Unicode is an issue. However, the DLLs are actually named differently. If you look in C:\winnt\system32 (or equivalent) on the machine where you installed VC++, you'll find that along with MFC42.DLL there is also a file called MFC42U.DLL, the Unicode version. Similarly for all the VC++ related DLLs. Basically, when you build a Unicode version of your program, it it linked against the Unicode DLLs. Therefore, if you try to run a Unicode program on a non-Unicode system, it will fail.

Anyway, what I'm getting at is that if you build a non-Unicode application, you can update MFC42.DLL without a problem, since it is non-unicode.

As for the redistributable files, in fact, the recommended way is to copy them from your VC++ CD. Do a search for "Redistributable Files" in MSDN and you'll find more info. The list of files allowed for redistribution can be found in the Program Files / MS Visual Studio folder and is called redist.txt.

Hope this helps.

------------------------
Derek Waters
derek@lj-oz.com

static member funcs/variables

moliate4-Apr-02 12:39

moliate

4-Apr-02 12:39

Use depends or dumpbin to see what modules you might need to include. There might also be version differences between modules in your build environment and on the target system.

In debug build some of the modules might be linked as their debug correspondance, for example mfc42d.dll instead of mfc42.dll.

/moliate

moredip4-Apr-02 12:06

4-Apr-02 12:06

OK, I've got some code which I cut and paste straight from the MSDN documentation on the static C++ keyword.....and it won't link Mad | :mad:

can anyone work out why? This is the code:

// C++ only

class SavingsAccount
{
public:
   static void setInterest( float newValue )  // Member function
      { currentRate = newValue; }             //    that accesses
                                              //    only static
                                              //    members
private:
   char name[30];
   float total;
   static float currentRate;    // One copy of this member is
                                //    shared among all instances
                                //    of SavingsAccount
};

// Static data members must be initialized at file scope, even
//    if private.
float SavingsAccount::currentRate = 0.00154;

I copied it into a header file, and I'm getting the following errors

Tracker.obj : error LNK2005: "private: static float  SavingsAccount::currentRate" (?currentRate@SavingsAccount@@0MA) already defined in Capture.obj
Tracker.obj : error LNK2005: "protected: static int  CTracker::a" (?a@CTracker@@1HA) already defined in Capture.obj
Tracker.obj : warning LNK4006: "private: static float  SavingsAccount::currentRate" (?currentRate@SavingsAccount@@0MA) already defined in Capture.obj; second definition ignored

By the way, this isn't just me nitpicking at MSDN, I have a very similar class that throws up the same errors, and I need to know why!

TIA,

Pete

Paul M Watt4-Apr-02 12:16

Paul M Watt

4-Apr-02 12:16

this line:

// Static data members must be initialized at file scope, even
//    if private.
float SavingsAccount::currentRate = 0.00154;

Needs to be placed into your .cpp file.

Currently it is in your header file. When it gets included into multiple files the linker tries to allocate multiple instances of the static variable, and that is why you are seeing that probrlm.

moredip4-Apr-02 12:48

4-Apr-02 12:48

Thanks!

Ok, so if you have a static member variable then it has to be provided with a global definition, which is what that line does, right? But what if the variable is a user-defined type? I'm getting LNK2001 errors for all of the static variables of user-defined types in my class. I'm guessing it's because VC++ doesn't know how to initialize them correctly. So here's what I've tried so far - The variables are declared in my header file as follows:

class CTracker
{
...
protected:
...
static C2DPoint **m_aCentroids;
static double ***m_aCentroidDirs;
static UINT *m_aNumPoints;
...
};

I then initialize them in my cpp file like this:

static C2DPoint CTracker::**m_aCentroids = NULL;
static double CTracker::***m_aCentroidDirs = NULL;
static UINT CTracker::*m_aNumPoints = NULL;

but i'm still getting errors like the following:

error LNK2001: unresolved external symbol "protected: static class C2DPoint * *  CTracker::m_aCentroids" (?m_aCentroids@CTracker@@1PAPAVC2DPoint@@A)

Any idea why?

Oh, and thanks again for your help so far (with this /and/ the function pointer thing!).

Pete

Derek Waters4-Apr-02 13:36

4-Apr-02 13:36

In your CPP file, you don't need the static on the front, and I think you've got the *s in the wrong place:

C2DPoint **CTracker::m_aCentroids = NULL;
double ***CTracker::m_aCentroidDirs = NULL;
UINT *CTracker::m_aNumPoints = NULL;<pre>

Hope this helps.
 

------------------------
Derek Waters
derek@lj-oz.com

moredip4-Apr-02 13:41