|
|
shuzh wrote: 这个东西 貌似很好弄袄
Exactly.
|
|
|
|
|
First you should make up your mind if you want to read the file line by line or read the entire file into a buffer.
In case of the former option use CStdioFile::ReadString() method, for the latter use CFile::Read().
|
|
|
|
|
Rakesh5 wrote: if(docfile.open(....))
docfile.read(preadbuf,docfile.getlength());
This will not even compile. If you want to know why a particular piece of code does not work, at least show the actual code.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"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
|
|
|
|
|
Just a thought. But here goes:
You seems to read the file as Unicode, that way every character consists of two bytes in the file.
If docfile.getlength() reports the file size in bytes, then you get your 50%.
An example, suppose the file is 50 bytes.
docfile.getlength() returns 50.
But you can read 25 Unicode characters from it.
Makes sense?
Alcohol. The cause of, and the solution to, all of life's problems - Homer Simpson
|
|
|
|
|
I have a worker thread for example,
DWORD ThreadProc(void* pVal)
{
while()
{
pcEdit->SetWindowText("Status");
pcEdit2->SetWindowText("Status2");
}
}
Is it okay to update UI this way from the thread? Or how should I do? Anybody can explain in simple words?
The above actually works fine. But mate says I shouldn't do it, but he doesn't say how to do it. 
----------------------------
286? WOWW!
|
|
|
|
|
The right way to do it is to post messages to the thread that owns the UI.
Use the PostMessage[^] API to post messages.
For SetWindowText post the WM_SETTEXT[^] message.
The problem that can occur is such scenarios is when both the worker thread and the thread that owns the UI simultaneously updates the control. For SetWindowText, this may not be a problem because the function does the same thing of sending the WM_SETTEXT message.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
«_Superman_» wrote: The right way to do it is to post messages to the thread that owns the UI.
You mean I should post the message straight to the control right?
«_Superman_» wrote: For SetWindowText, this may not be a problem because the function does the same thing of sending the WM_SETTEXT message.
You mean I can go ahead with myCtrol->SetWindowText()? Then which controls/APIs exactly make the problem?
----------------------------
286? WOWW!
|
|
|
|
|
_8086 wrote: You mean I should post the message straight to the control right?
No. Create a custom message and post the custom message to the UI thread.
The custom message handler in the UI thread can call SetWindowText.
_8086 wrote: You mean I can go ahead with myCtrol->SetWindowText()?
It is cleaner to send a custom message to the UI thread.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
Here[^] is an excellent article you should read before starting to work with threads. It will cover a lot of important points and traps when working with thread (it also has a section answering your question).
|
|
|
|
|
I hope you've resolved the problem by now?
However, take this as a rule while doing multi-threaded programming: Never manipulate an UI element from a different thread than what owns it instead.
Like others said, post a message to the thread that owns the UI element, and have it manipulate the control for you.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
 My qustion is Why this happened???
if sibling window paint by Z-order according to MSDN doc, the button should not be painted after the dialog.
http://msdn.microsoft.com/en-us/library/dd183426(VS.85).aspx[^]
--------------------------------------------------------------
Do the follow simple step you will see the "magic" button:
1. Create MFC SDI project
2. At [resouce view], Add a dialog and set style child.(WS_CHILD)
3. Add this code to the *view.cpp to create to child window:
#define BTN1 10101
int CTestView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
if (CView::OnCreate(lpCreateStruct) == -1)
return -1;
m_dlg.Create(CTestDlg::IDD, this);
m_dlg.ShowWindow(SW_SHOW);
RECT rect;
rect.left = 10;
rect.top = 100;
rect.right = 110;
rect.bottom = 125;
m_btn.Create(_T("testBtn"), WS_VISIBLE | BS_PUSHBUTTON, rect, this, BTN1);
return 0;
}
* CTestDlg m_dlg, CButton m_btn is member of the CTestView
* Z-order can be checked either by Spy++ or GetWindow API
You can fix the problem by add WS_CLIPSIBLINGS style of the button.
m_btn.Create(_T("testBtn"), WS_VISIBLE | BS_PUSHBUTTON | WS_CLIPSIBLINGS, rect, this, BTN1);
|
|
|
|
|
My guess is you should be creating the button in your m_dlg::OnCreate object, not in CTestView::OnCreate.
|
|
|
|
|
thanks, Eric Haddan
I use Button just to show the problem, it will be the same if two dialog created as child of CTestView
The problem is: because sibling window paint in z-order(not as MSDN said), window in the lower order paint latter,makes window showed, but not active.
|
|
|
|
|
Is there any easy way to shift or swap elements inside vector?
For example if I have a vector that contains:
A B C D E F
and I want to swap elements B and C to read
A C B D E F
Thanks in advance!
-Rob
Whoever said nothing is impossible never tried slamming a revolving door!
|
|
|
|
|
|
Perfect.
Thank you!
Whoever said nothing is impossible never tried slamming a revolving door!
|
|
|
|
|
Hi there,
I am using VS 2008 Standard and have a problem compiling the following small C++ code snippet:
template <typename ArrayElement>
class Array
{
public:
virtual void split( Array<Array*> *result = 0)
{
if( result != 0)
{
result->clear();
}
}
void clear()
{
}
};
void main(void)
{
Array<int> a;
a.split();
}
The code itself here does not do anything really useful as it has been simplified to demonstrate the nature of problem which occurs with my real Array implementation: the code does not compile!! And I really can't understand why?? Some kind of recursion in evaluating the template seems to happen here. BUT: Note the underlined "virtual" keyword in the code above. Leave this away and suddenly the code compiles?!?  This does not make sense to me - what has the successful compilation to do with "virtual" functions in this case??
For my "real" Array class I must be able to have all the member functions virtual to overrride them in derived classes. So the solution can't be to just leave the functions non-virtual. Additionally the data type shown here ( Array<Array*> ) for the restult of the "split" method shall not be changed as this data type seems to make a lot of sense in my mind. The returned data is also an array - an array of arrays to be exact.
So WTF can I do to make this work? Any help is really really appreciated 
Thanks,
Oli
|
|
|
|
|
|
(nevermind)
modified on Friday, September 4, 2009 12:23 AM
|
|
|
|
|
The problem mentioned in the links is different from the OP here.
The links talk about a template member function.
The OP talks about a virtual member function of a template class.
That is perfectly valid.
Try making the clear function virtual.
virtual void clear()
This works perfectly.
I'm curious about the syntax of the function
virtual void split( Array<Array*> *result = 0)
What is the intention of declaring the parameter as Array<Array*>?
There must be a better way of doing this.
Incidently changing this to something like Array<int*> does compile.
I'm not sure why the code compiles when omitting the virtual keyword in the original code.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
«_Superman_» wrote: Try making the clear function virtual.
virtual void clear()
By changing the function member "clear" to "virtual" the compiler still generates code until infinity. So I can't see any difference here. Btw: In my "real" implementation "clear" exists and IS virtual.
«_Superman_» wrote: I'm curious about the syntax of the function
virtual void split( Array<array*> *result = 0)
What is the intention of declaring the parameter as Array<array*>?
There must be a better way of doing this.
Well the "split" functions takes the original Array (*this) and generates several sub arrays of the same type from it. These resulting arrays shall then be returned als as an array of arrays. That's the meaning of this param. In my original implementation however there are several more parameters which define how to split the array and the result param is declared as "Array<Array*> &result" as I do not allow to provide no result container. For this synthetic code demo I have changed a few things compared to my "real" implementation which have nothing to do with the compile problem but help to review the issue.
As you can see I want to consistently use Array wherever possible as everything shall be usable in the same way.
|
|
|
|
|
The issue is the call to clear, not the existence of split...which makes me think that VC++ is being eager in instantiating virtual methods - I'm guessing it's a slight bug in VC++ as g++ compiles your code quite happily..
See, when VC++ instantiates the call to clear, it needs to instantiate the template class Array<Array<ArrayElement>*>. It wants a vtable for that class, so it'll need an instantiation of split for that class. While instantiating split, it'll need to instantiate the call to clear, so it'll instantiate the class Array<Array<Array<ArrayElement>*>*>....
And so on, ad infinitum...
I think this is demonstrable by changing clear() to be
void clear()
{
split();
}
g++ won't compile this, giving an error message very similar to the VC++ warnings you were getting.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: See, when VC++ instantiates the call to clear, it needs to instantiate the template class Array<array<arrayelement>*>. It wants a vtable for that class, so it'll need an instantiation of split for that class. While instantiating split, it'll need to instantiate the call to clear, so it'll instantiate the class Array<array<array<arrayelement>*>*>....
And so on, ad infinitum...
Yes, I totally agree with you here and already knew that this happens. But it makes no sense to me as the compiler should only generate code that is USED. The code that the compiler generates here is not used anywhere - it COULD be used but it's not. Leave away the "virtual" keyword and suddenly it compiles without problems. Thinking of it I see no difference between the two versions as the compiler could also generate code until infinity without the "virtual" keyword. For me it seems like a VS 2008 compiler specific issue and I will certainly try the GCC compiler soon. (Must prepare my full project for that however.)
Stuart Dootson wrote: void clear()
{
split();
}
g++ won't compile this, giving an error message very similar to the VC++ warnings you were getting.
Err, what you are doing here is an OBVIOUS recursion that could not even be executed without stack overflow  The one in my code example isn't. What it's really about is code generation that does take place although the generated code is not actually needed. I will certainly never ever use a Array<Array<Array<Array<Array<Array<Array<Array<ArrayElement>...> container ANYWHERE So why does the compiler think I will?
|
|
|
|
|
o.kauert wrote: But it makes no sense to me as the compiler should only generate code that is USED.
VC++ has historically had issues with instantiating more than it necessarily needed with templates.
o.kauert wrote: Err, what you are doing here is an OBVIOUS recursion that could not even be executed without stack overflow
Yes it could be executed. The condition within split (if (result != 0)) will terminate recursion at run-time. However, the compiler cannot reliably and economically perform the static analysis required to see that and know that the first call to split from clear will terminate the recursion, meaning it doesn't need an instantiation of clear to be called at that point.
o.kauert wrote: What it's really about is code generation that does take place although the generated code is not actually needed. I will certainly never ever use a Array<Array<Array<Array<Array<Array<Array<Array<ArrayElement>...> container ANYWHERE So why does the compiler think I will?
Because it's unable to see as far as you - it doesn't have the knowledge of your design intent. It has to follow pre-defined rules about what to instantiate.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
