How to LPCTSTR Convert to char *
in [MFC]
|
Prev: why is CoUninitialize being called in CDHtmlDialog::Navigate
Next: A little help with a LNK2019 error?
From: Mihai N. on 7 Dec 2006 00:31 "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in news:Xns9891D6F0A9AE1MihaiN(a)207.46.248.16: >> One approach I am seriously considering is to put all hardware >> interface code with those needs into independent processes and write >> all user interface as a separate process purely in Unicode. That >> would also simplify the modifications as the hardware vendors modify >> their systems and change their protocols. I do have a pretty good >> separation of modules within my code but separate processes would help >> greatly. Then all the Unicode-ASCII conversions would occur at one >> point: the interprocess communication system. > > Good software engineering practices are often helping internationalization. > It sounds like a very good solution, I would vote for that > (especially since I don't have to do the work :-) Oups, I did not pay attention, and did not notice the "independent processes" part (I was thinking "independent modules"). I agree with Joseph M. Newcomer, just DLLs will do great. And, in fact, you can define a nice interface and have them work like a plugin. Then you can add a new device without touching your main application. -- Mihai Nita [Microsoft MVP, Windows - SDK] http://www.mihai-nita.net ------------------------------------------ Replace _year_ with _ to get the real email
From: Ajay Kalra on 7 Dec 2006 01:03 Mihai N. wrote: > > You're right. All of those macros (and there seem to be a ton of them) are > > handy once you divine the mystery of their names :o) > You just have to learn the rules: > http://msdn2.microsoft.com/en-us/library/87zae4a3(VS.80).aspx > > He wanted "LPCTSTR to char *", meaning T to A = T2A :-) > Wont that be CT2A ? (In VS2002 and beyond) --- Ajay
From: Joseph M. Newcomer on 7 Dec 2006 01:06 One of the thing I did with my processes (in order to debug them sanely) was to ensure that either the client or the server could be started in any order, either one could be shut down while the other was running, including shut down without warning (such as crashing during debugging). Making this protocol robust was challenging, but it ultimately resulted in a completely bulletproof product. I didn't have a lot of choice because we still don't have the budget to rewrite the Win16 program (130K lines), but it is not a structure I would adopt voluntarily. joe On Wed, 06 Dec 2006 23:50:39 -0500, r norman <r_s_norman@_comcast.net> wrote: >On Wed, 06 Dec 2006 23:07:01 -0500, Joseph M. Newcomer ><newcomer(a)flounder.com> wrote: > >>See below,.,. >>On Wed, 06 Dec 2006 17:14:05 -0500, r norman <r_s_norman@_comcast.net> wrote: >> >>>On Wed, 6 Dec 2006 13:52:19 -0800, "Tom Serface" <tserface(a)msn.com> >>>wrote: >>> >>>>I'm actually making all new programs Unicode. It's not really that much >>>>difference once you get into it (at least it hasn't been for us). You do >>>>have to remember that a "char" is now more than one byte so things like >>>>strlen() won't work as they did before. This article might help you some: >>>> >>>>http://msdn2.microsoft.com/en-us/library/805c56f8(VS.80).aspx >>>>http://www.i18nguy.com/unicode/c-unicode.html >>>> >>> >>>I have no problem with all Unicode. That is fairly easy by avoiding >>>all "old-fashioned" strxxx" functions and using CString. It is my >>>having to deal with protocols specifying ASCII chars that is the >>>issue. One approach I am seriously considering is to put all hardware >>>interface code with those needs into independent processes and write >>>all user interface as a separate process purely in Unicode. >>**** >>You don't need separate processes, and in fact this introduces a lot of complexity (I have >>a Win16 app which is now 12 years old, and the way we got IT to run on Win32 was to write >>a 32-bit "co-process" which handles serial I/O, networking, and speech output. It wasn't >>a lot of fun, ultimately, but that system is still running supporting a few thousand >>users. >> >>I just isolate the 8-bit stuff into low-level communication modules, often DLLs. The real >>design issue arises as to whether you ever see 8-bit characters outside the module/DLL. >>These days, I favor doing the ANSI-to-T transformation inside the module so outside I can >>rely on the data being in T-mode, more and more commonly Unicode these days. It's the >>compelling reason I've been able to use to get my VS6 clients moved to VS.NET. >>**** >>>That >>>would also simplify the modifications as the hardware vendors modify >>>their systems and change their protocols. I do have a pretty good >>>separation of modules within my code but separate processes would help >>>greatly. Then all the Unicode-ASCII conversions would occur at one >>>point: the interprocess communication system. >>**** >>DLLs should work just as well, and avoid the complexities of separate processes. That's >>one of the reasons I now use T-mode exclusively; if I'm receiving CStringA data, I make >>sure it is CString data before I send it out, and I accept CString data and convert it to >>CStringA internally before sending it to the device. A couple #ifdefs make this very >>efficient when T==A. >>**** > >(I prefer bottom posting) > >Yes, yours is a much easier method. Separate processes involve >ensuring that all them get started properly and then that they all get >stopped properly, especially if one of them develops a problem (not >that any of my programs ever has problems!) not to mention having a >more intricate interprocess communication method. > >Thanks, again. > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 7 Dec 2006 01:11 Plug-in technology is great. I've used it a couple times to replug various DLLs; key is a clean communication mechanism. In my case, a set of well-specified methods at the interface coming in and using only SendMessage and PostMessage to communicate from the DLL to the main app. I just pass in a CWnd * for notifications. The methods in fact translate to calls to function pointers via GetProcAddress, so the DLLness is hidden. Unfortunately, I can't tell anyone yet what I did this for, because the product has not been released, but what I had was a DLL that simulated the hardware, and when the beta hardware was released, we wrote a new DLL that actually talked to the hardware, and when the pre-release hardware was released (with a completely different device driver) we just recoded the DLL once more. The app didn't change at all. joe On Wed, 06 Dec 2006 21:31:45 -0800, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: >"Mihai N." <nmihai_year_2000(a)yahoo.com> wrote in >news:Xns9891D6F0A9AE1MihaiN(a)207.46.248.16: > >>> One approach I am seriously considering is to put all hardware >>> interface code with those needs into independent processes and write >>> all user interface as a separate process purely in Unicode. That >>> would also simplify the modifications as the hardware vendors modify >>> their systems and change their protocols. I do have a pretty good >>> separation of modules within my code but separate processes would help >>> greatly. Then all the Unicode-ASCII conversions would occur at one >>> point: the interprocess communication system. >> >> Good software engineering practices are often helping internationalization. >> It sounds like a very good solution, I would vote for that >> (especially since I don't have to do the work :-) > > >Oups, I did not pay attention, and did not notice the "independent processes" >part (I was thinking "independent modules"). >I agree with Joseph M. Newcomer, just DLLs will do great. >And, in fact, you can define a nice interface and have them work like a >plugin. >Then you can add a new device without touching your main application. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 7 Dec 2006 01:12
That's assuming he really meant "char *" instead of "pointer to string", in which case the question is not actually well-specified. joe On Wed, 06 Dec 2006 21:04:18 -0800, "Mihai N." <nmihai_year_2000(a)yahoo.com> wrote: >> You're right. All of those macros (and there seem to be a ton of them) are >> handy once you divine the mystery of their names :o) >You just have to learn the rules: > http://msdn2.microsoft.com/en-us/library/87zae4a3(VS.80).aspx > >He wanted "LPCTSTR to char *", meaning T to A = T2A :-) Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |