|
Another way, which I have used, is to put the strings into large memory memory buffers one after the other (with terminating zeros between each, of course) and then store pointers to them in a CArray<>.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
I want to do a Total Commander in Visual C++, but I didn't find any control suitable to look like a pane.Can anyone give me some hints, please?
Thanks very much.
|
|
|
|
|
Adriana Frunza wrote: I want to do a Total Commander in Visual C++
  you mean, even with the 16 bits look and feel ?
look at CSplitPane for the pane...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
I'm using Visual C++ 6 unfortunately.Where can I find this class?
|
|
|
|
|
|
This is probably a bit embarrassing, but I have set up some static controls with control variables, but I have totally forgotten how to set the text based on a floating point number!
// export version
c_ExportVersion.SetWindowText(version);
works fine, as "version" is just a character string
// fieldwidth
c_BEAMWIDTH.SetWindowText(fieldwidth);
does not work fine, as "fieldwidth" is a floating point number, I've tried going via CString but that didn't work, and sprintf seemed to be the wrong idea too
(eg tried
CString str = fieldwidth;)
I'm sure this is very basic but I've been away from Windows for a while, so am still re-finding my feet.
thanks in advance
|
|
|
|
|
CString str;<br />
str.Format("%.5f",fieldwidth);<br />
c_BEAMWIDTH.SetWindowText(str);<br />
This will print your float with 5 decimals after floating point.
|
|
|
|
|
Many thanks. I don't know how I missed the "format" class member of CString, but as I said, it's been a while!
|
|
|
|
|
In continuation to Mr. Cedric Answer, you can also you wsprintf, if working on Non MFC application
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Hi
I need to exchange large Strings between my own dll and my programm.
Any Idears ??
THX
|
|
|
|
|
extern string mystring;
Or what do you mean with "exchange" ?
~RaGE();
|
|
|
|
|
If the DLL is loaded into your processes address space, you can already see each other's memory - no extra steps required. Just allocate space for the string, and pass it to a method in the DLL. Or pass the memory to a method in the DLL and have it return the string in it. Or have the DLL allocate the memory and return it to you. Etc.
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: Or have the DLL allocate the memory and return it to you.
Don't forget the let the dll free the memory it has allocated. Every module exe/dll is resposible for its own allocated memory.
codito ergo sum
|
|
|
|
|
Actually, I abhor writing hand-off memory functions, where memory is allocated by the called function and returned from it with the understanding that the caller is now responsible for it. IME, there seems to be an "out of sight, out of mind" mentality where if the caller did not make an explicit call to a memory allocating function/operator that they are familiar with (new, malloc(...), SysAllocString(...), etc.), they tend not to realize that they are now responsible for deallocating it.
I tend to write functions that need memory such that they take a pointer to a previously-allocated block of memory and the size of that block. That way, it is clear that the caller manages the memory.
I was just detailing examples for the poster. Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free (as long as it was allocated while in the context of your process, and not another).
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
James R. Twine wrote: Besides, I am fairly certain that a DLL loaded into your address space can allocate memory that you can free
It used to be no problem, on OS like Win9x and Win2000. We had writen our own Dll who encrypted some
data returning the BYTE* pointer to the encrypted data which was freed after use in our application. Without any problems what so ever.
We then moved to WinXP and our application crashed on the the delete[] of the memory returning in a access violation.
Found this on the net:
Potential Problems When Crossing DLL Boundaries
It is not possible to allocate memory in a DLL (either explicitly with malloc / new or
implicitly with aforementioned strdup) and pass the pointer across the DLL boundary into
the process space to free it, when the DLL and the application are using different copies
of the CRT (C-RunTime) libraries. This will cause a nasty memory access violation or worse:
corrupt the heap! When you bump into an assert in the CRT lib when it tries to execute free(),
you will know you have run into this very problem.
Memory is only valid for the copy of the CRT where they were allocated. This means that when
you are using two different CRT libraries (LIBCMT.LIB and MSVCRT.LIB for example) together,
you cannot expect one to correctly free something the other has allocated. Because they most
probably are using different heap managers, the heap runs the risk of becoming corrupted when
you run the application in release mode! Pity the programmer who has to track the bug that
crashes his application this way.
So its better safe the sorrow.
codito ergo sum
|
|
|
|
|
Hello,
I've developed an application for PocketPCs. I'm using Embedded Visual C++ so I released differents versions based on the PocketPC architecture (ARM/XSCALE, MIPS, SH3...)
However, most users don't know which architecture their PPC is based on. So I'd like to ship a single setup app that will install the right version according to the PocketPC connected (via ActieSync). But I don't know how to make such a setup app.
Can someone help me?
Regards,
Allad
----
Navigator - Your best alternative to Windows Explorer
|
|
|
|
|
I often find MFC projects - also here on Code Project - where the STL is used.
Everytime i wonder why someone do this, there are equivalent classes in the MFC.
If i don't want to use the MFC ok, but if i make a control which is derived from a MFC class, why shouldn't i use MFC containers too? MFC has CMap, CArray and CList, so there is no need to use STL.
Are there any reasons to use the STL in a MFC project?
|
|
|
|
|
first of all, STL is the Standard C++ library, which means it compiles on every plateform (windows, linux, mac, solaris, etc...) without changing the code, but only recompiling...
secondly, MFC are targetted for windows, and most of the classes provided there are wrappers, which means they provides some additionnal layers (which may result in more slow code).
and finnaly, MFC classes are generally usd for display purpose (GUI oriented at least), while STL are for background treatments (controler layer of MVC model).
any more questions ?
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: first of all, STL is the Standard C++ library, which means it compiles on every plateform (windows, linux, mac, solaris, etc...) without changing the code, but only recompiling...
secondly, MFC are targetted for windows, and most of the classes provided there are wrappers, which means they provides some additionnal layers (which may result in more slow code).
and finnaly, MFC classes are generally usd for display purpose (GUI oriented at least), while STL are for background treatments (controler layer of MVC model).
any more questions ?
Have you even read my post?
|
|
|
|
|
have you tried to understand mine ?
it is not because you create your own control (which is GUI part here, i conceed) that everything you do goes to that layer... maybe there are so internal treatment whih have nothing to do with rendering.
moreover, know that CMap and CArray are crap !
ps: thank you for the rate 
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: have you tried to understand mine ?
Yes, but the question was not STL or MFC for portability, the topic is STL in MFC projects.
If my project makes usage of MFC it's not portable anymore, no matter if my container classes are portable or not.
Therefore you whole post has nothing to do with the topic.
|
|
|
|
|
Good grief. Just because you're using MFC doesn't mean you have to its inferior container classes! I use STL containers in all my MFC projects because it gets the job done faster and with less code than the MFC equivalents.
|
|
|
|
|
ABuenger wrote: If my project makes usage of MFC it's not portable anymore
yes
ABuenger wrote: no matter if my container classes are portable or not.
no.
consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
TOXCCT >>> GEII power
[toxcct][VisualCalc 2.20][VCalc 3.0 soon...]
|
|
|
|
|
toxcct wrote: consider the case where you do a general treatment on datas in background... these treatments have nothing to know about the GUI, whether it is mfc, owl, etc...
if you don't care about what I say, let it down. if however, you still want to understand my reasons to answer so, have a look a my VisualCalc article. you will - i hope for you - understand that i can easily interchange the user interface depending on the plateform i target my project.
so, of course MFC is not portable further than windows, but in my case, ONLY the GUI is not portable, so, i don't have to rewrite my whole code. so, i believe that's why STL is used so much... portability is an important point in software development industry, especially when you have to code very fast...
Ok, in that case it makes sense to use STL. But i am talking about custom MFC controls which will never be ported and aree just standalone MFC extensions.
For example CPPTooltip and CTreePropSheetEx on Code Project. These controls will never be portable, and if i derive a control from a MFC class it doesn't make sense to have a STL map in my class.
|
|
|
|
|
can you be a little more polite? 
VuNic
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
