C / C++ / MFC

Loading two versions of Common Controls

13-Jul-13 8:55

Unix like fork is quite foreign in windows. Cygwin simulates fork on windows: http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork[^]
There are many "unix simulation libraries" available on windows (including cygwin, interix, ...) but I wouldn't recommend building on top of these if you don't have to. My opinion about the cygwin fork simulation: In the unix world many tools/scripts make use of spawining other processes and processing data by piping the output of one process to another process. Running the same script/program "network" on windows/cygwin is multiple times slower than running the same command on linux if it involves a lot of fork invocations (for example a simple ./configure and ./make combination is always much faster on linux).

Re: Exec under windows

jschell13-Jul-13 11:03

jschell

13-Jul-13 11:03

It is similar and different.

Jonathan Davies12-Jul-13 1:35

12-Jul-13 1:35

Using VS2008 Professional (v 9.02) in Debug mode on Windows 8 to write a Win32 program I have two versions of Windows Common Controls ComCtl32.dll loading. On a call to: CreateDialogParam one: Product Version 6.2.92.../File Version 5.82.92... loads then on a call to SetupDiGetClassImageList another one loads having Product Version 6.2.92.../File Version 6.10.92.

I only noticed when having problems trying to use a feature of ListView header (up/down sort arrows) that various Googled sources attribute to needing a later version of ComCtl32.dll.

I had a look at the Manifest but see nothing seems relevant there. Switching to Release mode had no effect.

Is it possible to just load one version, preferably the later version loading?

The above with slightly more detail from the VS Output window is below for reference if needed.

In Debug mode:
Between:

hSelectDlg = CreateDialogParam(hInst, MAKEINTRESOURCE(IDD_DIALOG_SELECT), 0, DialogProc, 0);

and entering

BOOL CALLBACK DialogProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)

Loaded 'C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.9200.16384_none_bf100cd445f4d954\comctl32.dll'

then on a call:

BOOL b = SetupDiGetClassImageList(&m_spImageData);

Loaded 'C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.9200.16579_none_8937eec6860750f5\comctl32.dll'

Randor 12-Jul-13 15:01

Randor

12-Jul-13 15:01

Hi,

Have you tried adding a /MANIFESTDEPENDENCY entry for common controls specifying version six and above? Follow the instructions here:

Enabling Visual Styles[^]

Best Wishes,
-David Delaune

Jonathan Davies12-Jul-13 23:33

12-Jul-13 23:33

David,

No I hadn't tried anything in the manifest. I've had a quick scan of the link you set and (initially)took the quick option of pasting in the example #pragma just as it's given for a version version= '6.0.0.0' to set the version from a .h file. No obvious difference yet as its still loading a v5 and a v6.

Of relevancet, I have a WTL/ATL version that I can step through side by side with the Win32 version and the WTL/ATL only loads one ComCtl32.dll, the v6.

I'll have a look in more detail later.

Thanks

... controls_6595b64144ccf1df_5.82.9200.16384_none_bf100cd445f4d954\comctl32.dll
...
... controls_6595b64144ccf1df_6.0.9200.16579_none_8937eec6860750f5\comctl32.dll

Jonathan Davies13-Jul-13 9:05

13-Jul-13 9:05

Adding manifest as recommended prevents v5 ComCtl32.dll loading, just the v6 but as soon as I open the my dialog with my ListView control on it's gone. Just flickers on the screen and disappears. Calling

C++

InitCtrls.dwICC = ICC_LISTVIEW_CLASSES;
BOOL bInit = InitCommonControlsEx(&InitCtrls);

or not doesn't affect it.Stripped out a most of the functionality but it still happens ...

Jonathan Davies14-Jul-13 5:25

CStringArray vs. CArray<CString>

14-Jul-13 5:25

The dialog with listbox using one ComCtl32 6 and not loading a v5 at well that flicked out of existence didn't bode too well for debug success so I started from scratch putting in a manifest line at the beginning and it displays. Only one ComCtl32 6.0.9200.16579 is loaded so that looks like success (apart from having to cut'n past stuff stuff).

Thanks

hans.sch11-Jul-13 5:33

11-Jul-13 5:33

Hi,

I am wondering what might be the advantage of CStringArray over CArray<CString, LPCTSTR>. The background is that I am planning to implement a CStringArray-like template class which is either explicitly ANSI or explicitly Unicode, and would like to implement it as CArray<CStringA, LPCSTR> and CArray<CStringW, LPCWSTR>, respectively.

Thank you for any comments.

Hans

pasztorpisti11-Jul-13 6:25

11-Jul-13 6:25

I have never mastered the usage of MFC container classes but I have an advice: support only unicode unless you are forced to support ansi. WinNT uses unicode/UTF16 inside, the codepaging/ansi api is just heritage from older windows versions. Supporting both is just a waste of time and unecessary complication if you don't have to support Win9x.

EDIT: Regarding the difference between CStringArray and CArray<CString...> I have a tip: The old versions of MFC didn't contain any templated containers, those mfc versions had only some non-template containers for a few types and CStringArray was one of them (among the others like CByteArray). I guess CStringArray exists just because of backward compatibility. CString didn't have reference counting in some older versions of MFC so in theory it is possible for a specialized CStringArray to reallocate the array memory without copying strings if CStringArray knows the internal implementation of CString, but a templated CArray has to work with copying/deleting. With reference counting a general CArray can do a relatively good job and with today's move ctors it can be even better if MFC supports it.

hans.sch11-Jul-13 6:43

11-Jul-13 6:43

There are situations when I must support ANSI, for example when it comes to dealing with ANSI text files or serial protocols. I want to have the CStringArray functionality available for the must-be-ANSI situations while generally compiling for Unicode. Btw, I find MFC containers quite useful (unless, of course, you are using STL). The documentation is quite good, and you can debug-step through the source code.

pasztorpisti11-Jul-13 8:21

11-Jul-13 8:21

Do you receive single bytes/ascii or really ansi on the serial port? Many people confuse ansi with ascii or latin1. Similarly, many windows coders confuse utf16 with unicode (they are two different things) and wchar_t with a unicode character. Can you clearly separate these concepts because if not I can write you a very little mini tutorial about these here. I want to convince you that compiling your program only for unicode is probably enough. Btw, what is on the other end of the serial port and what kind of codepage do you use in the "ansi" text for communication, is the text bare ascii (characters below chr(128))?

Containers: No matter what containers you use, its easy to debug either implementation. One of the project I'm currently working on contains own container implementations (array, hashmap, ...) and even these containers are debuggable if you can adjust the autoexp.dat file of your visual studio accordingly to teach the debugger how to get out items from the container. When I choose containers I consider 2 aspects: portability to different platforms and whether I need hardcore performance optimization later in the project or not. If we consider portability then stl is a much better choice than mfc containers, thats why I never really used mfc containers. Writing your own containers isn't practical in 99% of the projects.

hans.sch11-Jul-13 9:14

11-Jul-13 9:14

Well in fact I should use proper terminology. When I said "ANSI" I meant 8-bit character stuff. When I said "Unicode" I meant 16-bit characters. Speaking of Unicode code points, mostly in the range 0000 through 007f. In other words, ASCII characters in different representations. But this discussion is getting beside the point. My question was, what is the advantage of CStringArray over CArray<CString, LPCTSTR>? Rephrase: Why is there a CStringArray class when CArray<CString, LPCTSTR> has the same functionality? Or does it not?

pasztorpisti11-Jul-13 9:29

11-Jul-13 9:29

Here is a nice page that can help you in choosing between the two options: http://msdn.microsoft.com/en-us/library/y1z022s1%28v=vs.71%29.aspx[^]. In my previous post I mentioned that in the early days of MFC there were no template usage in the mfc library so they created several array implementation for some basic types like WORD, CString, Int,... Later they introduced templated classes like CArray<> but they kept the earlier container classes as well for backward compatibility so as to keep old legacy code compilable. Today you can use either of them but probably the CArray<cstring> is preferred in new code.

I would compile only a single unicode-aware version from my program and I would convert my strings to ascii only before sending them over serial connection and converting them back after receiving the string from serial but of course this is your choice. If you used utf-8 to represent strings then the conversion would be unnecessary - with utf8 you should convert between utf8 and utf16 only when you call winapi that has string parameters and/or return values. I like using utf-8 internally because its compatible with ascii, unicode aware, and its very easy to port to unix like systems at the same time.

hans.sch11-Jul-13 10:34

11-Jul-13 10:34

Thanks for that link... actually it doesn't tell me why I should use one or the other. There table in that page lists two differences between CArray and CStringArray: 1. The former uses templates while the latter doesn't - well, that is obvious. 2. CArray isn't type safe while CStringArray is - but I fail to see why. A CArray<CString, LPCTSTR> can only contain CString objects, so what should be type unsafe? So actually, my question remains open Frown | :-(

Regarding your advice, I have to deal with tons of old code. Many parts of that code work well with Unicode, but I know some places that confuse bytes with characters, and I sure don't know all of them, and I just don't have the time to clean everything up. I will have to live with a mix of 16 and 8 bit character strings. Besides, it is a pity that there is no built-in or MFC UTF-8 string type in C++. I love Perl for that.

pasztorpisti11-Jul-13 13:01

11-Jul-13 13:01

I'm pretty sure that CStringArray and CArray<CString> provide the same functionality. If later you find out then its still an easy search and replace. I wouldn't worry about this choice. I myself prefer templates as in some cases templated containers are easier to handle (from other templates) than specific types like CStringArray.

The Serical Port Question?

Joe Woodbury15-Jul-13 12:00

Joe Woodbury

15-Jul-13 12:00

They provide the same functionality, though CStringArray is faster to add strings (it is specialized, so that makes sense.)

dave62112711-Jul-13 0:27

11-Jul-13 0:27

Hello,
I got a question about the Win API with C++,
Some problems in the use of the
OpenComm(mbPortName, INQSIZE, OUTQSIZE);
The "COM1" to "COM32" is OK! But The "COM32" or higher always return error.
The function can't return ID to me.
How can I modify my parameter to solve this problems.
Thank you.

«_Superman_»11-Jul-13 1:19

«_Superman_»

11-Jul-13 1:19

OpenComm is now obsolete.
Use CreateFile instead as follows -

CreateFile(_T("\\\\.\\COM25"), GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++) (October 2009 - September 2013)

Polymorphism in C

dave62112711-Jul-13 2:43

11-Jul-13 2:43

Thank you very much.
But my project is develop in Visual studio 6.
There is no other way to do it?

Erudite_Eric11-Jul-13 6:06

Erudite_Eric

11-Jul-13 6:06

CreateFile is part of the Win api and has nothing to do with the version number of the dev studio you are using.

dave62112711-Jul-13 15:15

11-Jul-13 15:15

Thank you.
I am try to convert the code to "CreateFile" funciton.

Erudite_Eric11-Jul-13 6:08

Erudite_Eric

11-Jul-13 6:08

Does COM32 exist? Can you open it in hyperterminal? Does something else already have it open? Is it an exclusive device? Is it in device manager? Does it have a modem attached to it?

dave62112711-Jul-13 15:29

11-Jul-13 15:29

I can open COM32 or Higher in hyperterminal.
It is an exclusive device, and the device is "MOXA" device.
The one is support COM1 to COM256 that is use a configuration UI to setting it.
I can change any port to different COM port. and request and response data is ok in hyperterminal.