|
Ok. Are you looking for CreateWindow() to create the edit control, or are you wanting to know how to move (drag) a control?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
I only have experience to put a edit control on a dialog box. I do not know how to draw it in client area, and how to make it be able to dragged by mouse in client area.
Thanks.
|
|
|
|
|
xyhan wrote: I only have experience to put a edit control on a dialog box. I do not know how to draw it in client area...
The client area of a dialog is where the controls are located. Why do you think they are not one-in-the-same?
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Make sense.I tried the following code in OnDraw(CDC *pDC) function:
CEdit textbox;
textbox.ShowWindow(SW_SHOW);
The running error indicates there is no valid window handler. I do not know why.
|
|
|
|
|
You have not actually created the underlying window.
CEdit *textbox = new CEdit();
textbox->Create(...);
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
OK,Thanks very much.
Now my question is: How to draw it in its parent window?
|
|
|
|
|
It's usually not a good idea for a control to draw in an area that it does not own. If a control needs to do this, the correct way is to send a message to the parent and let the parent take care of its own drawing.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
Declare a CEdit member in your view. Create it in OnInitialUpdate (after checking to see that it's not already created). Keep it hidden by default.
Show it whenever you want to by showing the control (ShowWindow) and that's it.
Regards,
Nish
|
|
|
|
|
I've got some executable which runs with its cygwin.dll under windows and was compiled under cygwin.
It accepts to its stdin strings and read them with fgets();
if(fgets() == NULL)
return; //that is ctrl+z was pressed
This works if we run it from windows.
But if we run it thru win app with createprocess() and puts strings thru pipe to it it recieves them correctly and now we want to stop its reading stdin and write to it \032\n that is ctrl+z but its fgets compiled with cygwin does not recognize it as stop writing to me and fgets should return 0, it reads it as \032\n string!!!
and waits for another string to be written.
VC++ compiled console executable with fgets() correctly understand \032\n as ctrl+z and we can terminate it from win app.
What's the EOF symbol for cygwin compiled fgets?
9ine
|
|
|
|
|
If I'm interpreting your situation correctly...
There is no special *eof* character that you can embed in data coming through the pipe. *eof* is signalled to the process reading a pipe when the process that is writing the data closes its end of the pipe.
Regards,
Dan
Remember kids, we're trained professionals.
Don't try this at home!
|
|
|
|
|
To induce console app function fgets() return NULL as eof encountered we must write to pipe \032\n. This works with VC compiled console app.
I close write end of pipe believe me before reading from read end of pipe, but this will not affect even windows console app which reads lines from console with fgets(). Only passing to console stdin thru write pipe \032\n induce console app to quit from fgets() returning NULL as eof was encountered! You can even leave pipe unclosed!
But with cygwin compiled application niether works!? as its compiled fgets() interprets \032\n as a string!
I that makes sence?
9ine
|
|
|
|
|
Sorry, I don't understand what you are trying to describe.
Remember kids, we're trained professionals.
Don't try this at home!
|
|
|
|
|
Console app which reads stdin with fgets() untill it returns NULL.
If string read, fgets returns non-zero value, if ctrl+z\n read, fgets returns NULL.
case 1: VC compiled console app!
subcase A: lunch it from command line, type strings, type ctrl+z\n to quit it
subcase B: lunch it from win app thru createprocess(), write strings thru pipe to it, write \032\n bytes seq to pipe, console app will quit!
case 2: cygwin compiled console app!
subcase A: equal to subcase A in case 1.
subcase B: equal to subcase B in case 1. except that \032\n seq is interpreted as a string and does not force to return NULL function fgets() as in case 1, subcase B!!!
What to write to pipe of case 2,subcase B, to make cygwin compiled console app fgets() function to return NULL??????
9ine
|
|
|
|
|
You have to close the writing end of the pipe to signal an EOF to the process. This is what the command interpreter does when you press Ctrl+Z.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I close it believe me before reading from read end of pipe, but this will not affect even windows console app which reads lines from console with fgets(). Only passing to console stdin thru write pipe \032\n induce console app to quit from fgets() returning NULL as eof was encountered! You can even leave pipe unclosed!
But with cygwin compiled application niether works!? as its compiled fgets() interprets \032\n as a string!
9ine
|
|
|
|
|
Try sending it \004. Linux shells (which cygwin is based on) sometimes interpret Ctrl+D as an EOF character.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
useless!
fgets() compiled under cygwin interprets it as usual string!
9ine
|
|
|
|
|
I am getting an assert occasionally in the following
void CFile::Write(const void* lpBuf, UINT nCount)
{
ASSERT_VALID(this);
ASSERT(m_hFile != (UINT)hFileNull);
Basically This call is from another thread (worker thread)(thread B) to write to a file and this thread does not initially create the File Object . The file object is created by the main thread (thread A ).
The above assertion happens when B tries to write to the file after A has created the file .
I have tried to put a critical section where the common function to write to the file is called but still I see the assert .
Could this be because of my thread not being able to access MFC cFile Object correctly
Also this happens occasionally 2out of 10 times .
I also see that the file is finally getting written with contents for both thread A and B but this ASSERT is worrying me .
Any ideas ?
Engineering is the effort !
|
|
|
|
|
act_x wrote: I also see that the file is finally getting written with contents for both thread A and B...
If the possibility exists that both threads are wanting to access the file, I think you might need to wrap the read/write calls in a critical section (i.e., CCriticalSection).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
It's likely that thread A had not yet actually opened the file, or at least assigned m_hFile to the file handle, before thread B runs. Since there is an OS call, it is very likely the open operation is triggering a sleep operation which, in turn, is causing thread B to run if it has been created by that point.
I suggest not creating thread B until thread A has opened the file. An alternative is to have thread B wait on an event that will be signalled once thread A has opened the file.
A critical section should be used for read/write/close operations, but are a potential problem here since thread B could get it's time slice before thread A even enters its critical section to open the file.
Another option to look at is for thread B to open and close the file.
Also note that when you close the file, thread B must either be terminated (wait on it's handle, then close the file) or should check if the file handle is valid before performing the operation.
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 will change an the content of a node in a XML-File. It is no problem, to get the specific node and its content. But to change the content of the Node I have to use the function "InsertData" from the class IXMLDOMText. Therefor I have to initialize the IXMLDOMTextPtr. But every time I try this, I get the error message, that the left part of ->"Query Interface" has to point to a class... So what's wrong with that?
Below the pasted code to make it a little bit more understandable.
Thanks, Hanno
CString fileName;
CFileFind find;
BOOL findFile;
IXMLDOMDocument m_iDocPtr;
IXMLDOMNodePtr m_iNodePtr;
IXMLDOMTextPtr m_iTextPtr;
findFile = (find.FindFile(strPath+"\\"+"*.xml",0));
while(findFile != 0) {
fileName = find.GetFilePath();
m_iDocPtr->Load((_bstr_t)fileName);
m_iFr = m_iDocPtr->createDocumentFragment();
m_iNodePtr = m_iDocPtr->selectSingleNode("//HI");
m_iNodePtr = m_iNodePtr->selectSingleNode("//Hello");
_bstr_t hello= m_iNodePtr->text;
if (atoi(hello) == 0) {
m_iTextPtr = m_iDocPtr->createTextNode("something");
m_iTextPtr->insertData(2,"something");
}
}
|
|
|
|
|
I'm looking for some clarity here. I register two MultiDocTemplates. The only important difference between the two templates is different views.
I don't want the initial dialog that asks me to pick a template before the main window is displayed. I have an initial view already set to run.
Here's some code from my InitInstance()
// InitInstance()
m_pDocTemplate = new CMultiDocTemplate(
IDR_2DVIEW,
RUNTIME_CLASS(CCdataMFCdisplayDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(C2DView));
AddDocTemplate(m_pDocTemplate);
m_pDocTemplate = new CMultiDocTemplate(
IDR_OPENGL_VIEW,
RUNTIME_CLASS(CCdataMFCdisplayDoc),
RUNTIME_CLASS(CChildFrame),
RUNTIME_CLASS(COpenGLView));
AddDocTemplate(m_pDocTemplate);
// create main MDI Frame window
CMainFrame* pMainFrame = new CMainFrame;
if (!pMainFrame->LoadFrame(IDR_MAINFRAME))
return FALSE;
m_pMainWnd = pMainFrame;
// Parse command line for standard shell commands, DDE, file open
CCommandLineInfo cmdInfo;
ParseCommandLine(cmdInfo);
// Dispatch commands specified on the command line
if (!ProcessShellCommand(cmdInfo))
return FALSE;
// The main window has been initialized, so show and update it.
pMainFrame->ShowWindow(m_nCmdShow);
pMainFrame->UpdateWindow();
// Make a starter document
NewDocument();
// Create a default View
CChildFrame *pFrame = new CChildFrame();
CCreateContext context;
CCdataMFCdisplayView *pview = NULL;
context.m_pCurrentDoc = theApp.GetDocument();
context.m_pNewViewClass = RUNTIME_CLASS(C2DView);
context.m_pNewDocTemplate = theApp.m_pDocTemplate;
context.m_pLastView = NULL;
context.m_pCurrentFrame = ((CMainFrame*)AfxGetMainWnd())->GetActiveFrame();
if (pFrame->LoadFrame(IDR_2DVIEW,WS_CHILD | WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE | WS_VISIBLE, theApp.m_pMainWnd, &context))
pFrame->InitialUpdateFrame((CMyDoc*)theApp.GetDocument(),TRUE);
// nothing pertinent follows
|
|
|
|
|
I found my answer. For those interested parties, I have to handle the ON_FILE_NEW message.
|
|
|
|
|
hi,
i want to make a login application(like windows login) that blocks all other processes/windows including the task manager. the application should be a simple dialog
can anyone help plz?
thanks
|
|
|
|
|
The DS_SYSMODAL style, which was for 16-bit Windows, has been "replaced" with the WS_EX_TOPMOST style.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
