|
I created a modless dialog box using Createdialog Function.but it is returning null value.what might be the reason.Please let me know
kir_MFC
|
|
|
|
|
Check the error value using GetLastError.
Also, it would help if you post the line of code that fails.
|
|
|
|
|
CreateDialog((HINSTANCE)hinst, _S("ABORT"), hDlg, (DLGPROC)lpAbortDlg)
kir_MFC
|
|
|
|
|
From the error code and code that you posted, it looks like ABORT is not a dialog template defined in your resource.
|
|
|
|
|
I see 3 things that I would question...
1/ Why the cast to HINSTANCE? If hinst is not already good enough, what it is?
2/ Same question with lpAbortDlg. If it's not the right type already, maybe there's a problem there.
3/ _S("ABORT"). I know _T, but not _S. Maybe ABORT is a constant, and what you really need is:
MAKEINTRESOURCE(ABORT) ?
Another thing that has caused my dialogs to fail in the past is when they contain a control that cannot be created - ie, a custom window class that you have not registered. To check this, go to resource editor, and check the "do not fail" checkbox.
Good luck,
Iain.
I have now moved to Sweden for love (awwww).
|
|
|
|
|
GetLastError returning 1814
kir_MFC
|
|
|
|
|
kir_MFC wrote: GetLastError returning 1814
The specified resource name cannot be found in the image file.
Not too difficult really ...
|
|
|
|
|
using errlook tool which will give you information about the error code!
Beyond myself!
|
|
|
|
|
I want to use the FlexGrid control in a VC6++ project. When the project was created several weeks ago I unchecked ActiveX support because I didn't think I was going to need that. Now it turns out it has been requested.
I added the ActiveX FlexGrid control using the normal Project -> Add to Project -> Components and Controls. The code compiles with no errors and runs as long as I don't actually add the FlexGrid control to the Dialog form.
When I drop a FlexGrid control onto the Dialog form it compiles when no error. However, when I click on Run, nothing happens. My dialog form doesn't start up. If I delete the FlexGrid control from the Dialog form and recompile the application starts up and my dialog form is displayed.
I think this is being caused by the fact that I unchecked the ActiveX support when I started project. How can I now add ActiveX support to the project?
|
|
|
|
|
Call the function AfxEnableControlContainer in the InitInstance method of your CWinApp derived class.
|
|
|
|
|
I added the AfxEnableControlContainer function. But my dialog still doesn't come up. Also, the function call is looking for an argument. What would that argument be?
Thank.
|
|
|
|
|
Never mind. I found that I had to place the function call ahead of initializing my application instance. By doing that my dialog form now comes up. Thanks for the help.
|
|
|
|
|
Hi,
I have been programming for 10 years using Borland Builder C++, but now I want to migrate to VS 2005 (or maybe later 2009). I am strugelling with UI and MFC stuff. Could you please recommend a good book to learn (for C++ programmers)?
Most of my applications are stand alone exe with graphic editors (2D at the moment).
Thank you for your help,
Denny
|
|
|
|
|
|
Rewriting your application from C++ Builder to MFC will be a pain for you, since the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
I would recommend you take the leap to .NET and Winforms, you can still integrate your existing C++ code with the .NET code.
If you really don't want to use .NET, then consider looking at the GUI library Qt.
|
|
|
|
|
Snakefoot wrote: the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
Yes, the elegance of Builder. Build apps that are several times the size of a similar MFC app. Use a class library design that inevitably frustrates any attempt to do anything unique; key methods not declared virtual, etc. The elegance of Builder - build your own BloatWare.
MFC seems to be getting a bad rep in this thread. Let me see if I can set the record straight. MFC offers a highly developed class library that is properly designed; it can be customized in ways Builder can't even dream of. You build native C++ apps - no .NET runtime, no .NET dependencies, etc. The idea that .NET replaces native C++ as a platform for high-performance apps is delusional.
L u n a t i c F r i n g e
|
|
|
|
|
Very seldom you need a high-performance CButton og CEdit. Use the right tool for the job, and C++/MFC is not the best tool for building GUI applications.
If there are parts of the application that are performance critical, then one can implement these parts in unmanaged C++, and interop with them from .NET.
Btw. MFC has also become quite bloated after including the BCG library, so unless you want to go WTL then it is difficult to deploy a standard GUI application without dependencies.
|
|
|
|
|
Snakefoot wrote: C++/MFC is not the best tool for building GUI applications.
That is a matter of opinion. With practice and a decent knowledge base, it is possible to create compelling UIs quite quickly w/ MFC. The class library is designed in a way that makes it fast and easy to implement custom UI components, unlike Builder's.
Your own experience may have been negative with MFC; mine has been fun and productive.
[edit]
Truth be told, though, I do love WTL. Any new native C++ project I've started in the last couple of years or so has been a WTL app. It's not a very beginner-friendly framework, though - I wouldn't recommend it in this case.
[/edit]
L u n a t i c F r i n g e
|
|
|
|
|
I'm working with MFC every day, so yes you can build nice applications with this framework.
I'm just saying there are better frameworks out these, especially if used to the GUI library of C++ Builder.
|
|
|
|
|
Thank you all for your input - my experience with Builder is - fast to make a simple project, easy to make a user interface, but of course limitations when you get deeper and the size of the final exe is bigger because you have to ship the VCL.
Sorry, but I am still hazy about the book to learn VS 2005  . I think I will stay with the Builder. 
Thanks again,
Denny
|
|
|
|
|
|
Thank you for the link, a very good site, indeed,
Regards,
Denny 
|
|
|
|
|
First of all...I can't tell you how frustrated i am about this FD_WRITE event. I've been searching for quite some time explanations about how it works yet I'm still not able to understand it properly. 
Q1: Do i use FD_WRITE to communicate with the client application?
If yes...
Q2: FD_WRITE is triggered when the network buffer becomes full. What is this network buffer and why does it need to become full before sending the data?
Q3: In order to fill it up I should make continuous calls to send() until i receive WSAEWOULDBLOCK. But if i don't have enough data to fill it up, what should i do? And...why continuous calls to send()?
If no..
Q2: What should i do when the FD_WRITE event triggers?
Q3: Should i use the FD_READ event to send a response based on the data received from the client?
|
|
|
|
|
zoopp wrote: Q1: Do i use FD_WRITE to communicate with the client application?
Maybe, but you don't have to use it. If you are sending (a lot of) data you might be interested in this event. It is used for handling partial sends, that is if you send more data then the socket can push over the network at a given time.
zoopp wrote: Q2: FD_WRITE is triggered when the network buffer becomes full.
No, the opposite. If is triggered when the socket can be written to again (after a send with WSAEWOULDBLOCK), it tells you that the socket is ready to send more data. This is a simplified answer, it is also triggered in other cases, for the full documentation see MSDN[^]
zoopp wrote: Q3: In order to fill it up I should make continuous calls to send() until i receive WSAEWOULDBLOCK.
Yes, until that happens or you have sent all your data. Data will be copied in the socket's send buffer first, the WSAEWOULDBLOCK case only arises if you pump in data faster than the socket can handle (lot of data or slow connection).
zoopp wrote: Q3: Should i use the FD_READ event to send a response based on the data received from the client?
Maybe, you use this event instead of constantly polling the socket "is there more data for me? are there more bytes?". This event is triggered when the socket can be read, it tells you that the socket has more data.
For further reading have a look at examples, e.g. Winsock FAQ[^] (asynchronous sockets). Btw, I tried to simplify the answers... there is much more to talk about when it comes to efficient networking strategies.
Hope this helps and happy coding.
/M
|
|
|
|
|
Thank you for your reply. It made things clearer now.
I'll ask another question if that's ok. You said that FD_WRITE is used for handling partial sends but, according to MSDN, it will also trigger after a call to connect() or accept(). The event for these calls should be handled different than partial sends and the way I'd handle both situation would be by disabling FD_WRITE before accept()/connect(), enabling it back after and by moving the code that was supposed execute in FD_WRITE when a new client connects in the FD_ACCEPT event.
Is this a good way of doing it?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
(