C / C++ / MFC

3-Aug-10 17:51

as I've heard, the class wofstream narrows every thing when it writes to a file. that is it converts every wide character to a single byte one and then writes it to the file. in this way you can't have such a thing as:

<br />
wofstream out(L"foo.txt");<br />
out << L"unicode string";<br />

so there is one question: what's this WIDE class useful for?!! how you name it WIDE version of "ofstream" while it can't be used with wide characters?

and one more thing: why it takes a parameter of type char* as the file name? it's a wide class any way Smile | :)

«_Superman_»3-Aug-10 18:27

«_Superman_»

3-Aug-10 18:27

wofstream is a type definition of the basic_ofstream class with the wchar_t data type.
And so it supports wide characters.
The 2 statements that you have written are definitely possible.

«_Superman_»

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

Microsoft MVP (Visual C++)

Polymorphism in C

Joseph Marzbani3-Aug-10 19:15

3-Aug-10 19:15

no it's not! it just creates an empty file. I've tried it 10's times.

«_Superman_»3-Aug-10 20:02

«_Superman_»

3-Aug-10 20:02

Have you tried writing the BOM (Byte Order Mark) header in the beginning of the file?

«_Superman_»

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

Microsoft MVP (Visual C++)

Polymorphism in C

Joseph Marzbani3-Aug-10 22:02

3-Aug-10 22:02

yes I have. to be more clear, this damn class writes ASCII characters quiet well. the problem I have is about non-English characters.

<br />
wofstream of (L"FileName.txt");<br />
of << L"English"; // this works<br />
of << L"فارسی"; // this does NOT work<br />
of.close();<br />

Aescleal3-Aug-10 22:15

3-Aug-10 22:15

Have you tried calling std::basic_fstream<type>::imbue with the locale of the text you want to write?

Have a read of Kreft and Langer "Standard C++ IOStreams and Locales" for as many details as you can take and then a few more.

Cheers,

Ash

Joseph Marzbani3-Aug-10 22:47

3-Aug-10 22:47

no I have not, and thank you for your clue. I'll read it as soon as return back my home. and one more thing, could you please show me some more resources on these new things (STL::locals). I've no previous experience on that.

Aescleal4-Aug-10 0:32

4-Aug-10 0:32

Sorry, I don't know a good online resource for locales which is why I recommended Kreft and Langer's book.

However, Emilio (who posts on here a fair bit) wrote an article about plugging a UTF-8[^] codecvt facet for locales which may give you enough information to get started with part of locales. You can try modifying his code to read and write UTF-16/UCS2/UCS4 depending on your particular needs.

Cheers,

Ash

Joseph Marzbani4-Aug-10 2:03

4-Aug-10 2:03

thank you so much. Rose | [Rose]

for you

Aescleal3-Aug-10 22:05

3-Aug-10 22:05

It can be used with wide characters, no problem at all. The C++ 98 standard library assumes that all filenames are narrow characters so the first line you've presented won't compile on a standard conforming compiler - however some compilers provide the second form as an extension to the library. What's particularly brain-dead about the constructors are the fact that they take C style strings and not std::basic_strings, but that's another story.

The line you've presented works perfectly - it handles wide characters pretty well in my experience. What it stores them in the file doesn't really matter (as far as the standard library is concerned) provided you can read them back in the same form.

Cheers,

Ash

Joseph Marzbani3-Aug-10 22:53

3-Aug-10 22:53

no, don't get it wrong. in my case, when I have such a line as
of << L"فارسی";
It does not write ANY THING AT ALL into the file. strange, ha?

Re: Tooltips can't be shown

Richard MacCutchan4-Aug-10 3:26

Richard MacCutchan

4-Aug-10 3:26

Take a look at this article[^], you are not the first person to struggle with this.

It's time for a new signature.

Tooltips can't be shown

gaspher3-Aug-10 2:47

gaspher

3-Aug-10 2:47

Hello everyone!
I'm confronted by a strange problem:
When mouse is over a ToolBar of a FrameWnd, tooltip text can't be shown.
CMainFrame::OnCreate()
{
EnableToolTips();

}
BEGIN_MESSAGE_MAP
ON_NOTIFY_EX(TTN_NEEDTEXT, 0, myFun)

END_MESSAGE_MAP
BOOL CMainFrame::myFun(NMHDR *pNMHDR)
{
TOOLTIPTEXT *pTTT = (TOOLTIPTEXT *)pNMHDR;
...
pTTT->lpszText = "Prompt";

}
It works fine on my computer, even if comment the codes above off but set prompt on the toolbar resource,But it doesn't have effect on some other computers.
The computers are all runing simplified chinese edition of windows xp sp3, I use vc6 and manifest.
I'm a foreigner,I'm sorry for my poor English.
Any advice would be appreciated.

David Crow3-Aug-10 3:18

David Crow

3-Aug-10 3:18

gaspher wrote:
ON_NOTIFY_EX(TTN_NEEDTEXT, 0, myFun)

Have you tried:

ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTA, 0, 0xffff, myFun)
ON_NOTIFY_EX_RANGE(TTN_NEEDTEXTW, 0, 0xffff, myFun)

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Man who follows car will be exhausted." - Confucius

Re: Tooltips can't be shown

gaspher3-Aug-10 3:37

gaspher

3-Aug-10 3:37

Thanks for your reply!
I have not tried, I will try it tomorrow when i come back to company.
But why use the micro ON_NOTIFY_EX_RANGE? MSDN says "Note that the ID of a tool tip is always 0" in
the article "Handling TTN_NEEDTEXT Notification for Tool Tips".
I set a breakpoint in my response function , when move cursor over the toolbar button,
my funtion can be entered. But the tooltip just can't be displayed.

Re: Tooltips can't be shown

David Crow3-Aug-10 3:43

David Crow

3-Aug-10 3:43

gaspher wrote:
I set a breakpoint in my response function , when move cursor over the toolbar button,
my funtion can be entered.

Then my suggestion will likely not help.

Handling Abort for Long running operations in MFC

MuraliKrishnaP3-Aug-10 0:54

Re: Handling Abort for Long running operations in MFC

3-Aug-10 0:54

I am trying to find an easier way to handle Abort mechanism for long running operations. I tried googling all CP articles but, still I can't find a better way to solve my problem. My application has huge code base. I have to carefully design the Abort functionality without making major changes to existing code. I want the future programmers to understand and debug the code easily. Adding more complexity, the application creates GUI / Glyphs on the fly.

Here are some solutions I found on CP:
1. Using PeekMessage loop and PumpMessage during long running operations. - Not feasible for huge apps, not easy to debug. Abort will be on and off.
2. Using worker thread for long operations, main thread becomes free, post completion status to main thread after completing long operation. - Gives most responsive app but, needs redesign of total code, exception handling will be difficult.
3. Using worker thread for creating glyphs, performing long operations and all from one single Worker Proc. - Not at all recommended. Window handles cannot be easily used from other threads without using CWnd::FromHandle() or Attach() methods. If there are any SendMessage() calls, it will lead to lead locks.
4. Using UIThread. - Will show an awkward Abort dialog every time but, solves problem very simply without having to change major code. There are other problems, The UIThread Abort dialog shows as seperate task bar button. This can be made as part of main app by making it tool window or by creating hidden window as parent. But, as the main window is busy, showing UIThread dialog when main thread is busy is something I need to solve.

I read one article: http://www.drdobbs.com/184416859[^] but can't understand the way to make it work. I request you people to take a look. In this, the author creates a new UIThread and the InitInstance waits until the long operation is done. I can't understand how this makes the main thread responsive. I tried it and it didn't work.

As you can understand, I am seeing all combinations. The Dr Dobbs article showed hope initially but did not work for me. Please guide me with your experience.

Thanks,
Murali Krishna.

Aescleal3-Aug-10 1:10

Re: Handling Abort for Long running operations in MFC

3-Aug-10 1:10

I'd go for using the active object pattern [1] - that gives you parallism without bending your current code to much. "Just" make the classes with the long execution time methods active. It's similar to using worker threads but the implementation of those worker threads are (mostly) hidden within the classes so they appear like normal objects.

The bad news is that writing (or borrowing) the scaffolding to implement active objects can be a bit of a pain in the bum. However once you've done it it's fairly easy to make any class active by implementing a fairly thin proxy class to the app. Perhaps try it with a toy application and see if it's worth the pain?

Cheers,

Ash

[1] In brief the idea of the active object pattern is that every object has it's own worker thread. When method calls are made on the object the calls get queued and run whenever the worker thread is next idle. Return values are dished back to the calling function as futures - which look like normal variables but block when read until their completing worker thread signals them.

http://www.cs.wustl.edu/~schmidt/PDF/Act-Obj.pdf[^] describes the pattern but it may take several readings to avoid the "whoaaa, this is well over complicated!" feeling.

MuraliKrishnaP3-Aug-10 2:32

Re: Handling Abort for Long running operations in MFC

3-Aug-10 2:32

Ash,

Thanks for your quick reply. I am looking at the pdf and trying to understand. I think it will take a day or two.

BTW, I forgot to mention. My application uses CORBA synchronous RMI calls. I took a quick look of the pdf and saw some know issues.. didn't read completly.

Thanks,
Murali Krishna

MuraliKrishnaP3-Aug-10 2:43

Re: Handling Abort for Long running operations in MFC

3-Aug-10 2:43

My bad, I misread it. it is known uses. (not issues) Smile | :)

Aescleal3-Aug-10 5:31

Re: Handling Abort for Long running operations in MFC

3-Aug-10 5:31

If you're using CORBA then using the active object pattern shouldn't be too hard a concept to grasp. You can think of a CORBA object as an active object running in another process/on another machine.

One option you might have might be to stick the long running stuff in their own processes and use CORBA, although you'll loose a bit (a lot?) of efficiency that way. It could save you the balls ache of implementing the active object pattern though and all the other problems you have with multiple threads although if you're using a lot of complex types in the interface marshalling might be hell.

Cheers,

Ash

MuraliKrishnaP6-Aug-10 10:03