|
hi all,
i want to design text on my dialog box whether Text is in Static control or draw the text using DrawString .
i want text looks with single or multi outline,gradient,font,shadow or glow even any thing else
help me for this.
thanks.
modified 24-Jan-13 5:38am.
|
|
|
|
|
You can use the Custom Draw[^] feature of all Windows controls.
|
|
|
|
|
have any example for this...
|
|
|
|
|
The link given by Richard MacCutchan has the examples (as a link).
|
|
|
|
|
Did you even bother to go and read the section I gave you the link for?
|
|
|
|
|
|
|
Look at the error messages. They are telling you that certain external functions that you reference cannot be found within the project. Find out where these are supposed to be defined and ensure that they are externalised.
|
|
|
|
|
You are correct but how to find its definition?
|
|
|
|
|
you can find it in SimpleProfiler/ProfilerCallback.cpp
|
|
|
|
|
john5632 wrote: how to find its definition?
Well, it's your code so presumably wherever you declared those methods. If they are part of some library that you are using then ensure that the library is included in your linker options.
|
|
|
|
|
I was a graduate student in Tsinghua University in China.
I'm programming about NC Code Simulation System.
In this program, I used OpenCSG Library to perform a Solid Modeling.
By the way, the sample program supported by library which is programmed in Win32 App, is well operate, but the program that I produced in MFC doesn't well operate. The error is that OpenCSG doesn't draw solid.
How to use OpenCSG Library in MFC?
Please help me.
Best Reguards.
谢谢！
CODE PROJECT MEMBER 安胜（AnSheng)
|
|
|
|
|
Hi
I have created a console application (.exe), and we have used SetConsoleCtrlHandler for signal handling i.e. "CTRL + C" and Log Off and Shutdown Events.
We are properly able to handle the "CTRL+C" event but Logoff and Shut down events cannot be handled properly.
Following content is mentioned at MSDN:
========================================================
The system generates CTRL_CLOSE_EVENT, CTRL_LOGOFF_EVENT, and CTRL_SHUTDOWN_EVENT signals when the user closes the console, logs off, or shuts down the system so that the process has an opportunity to clean up before termination. Console functions, or any C run-time functions that call console functions, may not work reliably during processing of any of the three signals mentioned previously. The reason is that some or all of the internal console cleanup routines may have been called before executing the process signal handler.
========================================================
Please suggest how we can properly handle Logoff and shutdown event by our console application.
Or please suggest any other technique (if available) for handling the logoff and shutdown event by the console based application.
Thank You
Ashish Kumar verma
Software Engineer(VC++)
|
|
|
|
|
You need to show the code where you test for these conditions; maybe you are doing something wrong.
|
|
|
|
|
In .NET we have the System.IO namespace providing convenient classes for Sockects and Pipes which ay be used for interprocess communication. How can one implement this in oldskool VC6?
My requirements are as follows.
I am writing a plugin for some legacy software for which there is a SDK which I can only get to compile with VC++6.0 compiler. I want to interface this code with both .NET and JAVA. I was thinking of implementing either a Socket server or Namedpipe in C# to act a a bridge between the VC6 code and .NET/JAVA. Requests from VC6 would be in the form of byte[] arrays and the C# bridge would interpret these requests, route them and eventually reply to the VC6 code which is awaiting a response.
In summary I would like examples of the following in VC++6:
- Use of threads
- Socket/Pipes (or any other interproc comms method)
- Invoking a process (other than a shell call to an executable)
BTW non-MFC is required
Any suggestions would be great.
Best, Y
|
|
|
|
|
|
Thanks Superman,
Exactly what I wanted. Whenever I search msdn I seem to find it have to get relevant results. my only realy experience it with .NET/JAVA and therefore when looking I'm a little non-plussed when it comes to C++/MFC and what is possible.
Great
|
|
|
|
|
If you want to simplify things, rather than use the sockets or named pipes, you might consider these two other options for the .NET part:
1) C++/CLI to generate a bridge DLL from the C# code that loads and runs the VC 6 DLL.
2) PInvoke from C# to load and run the VC 6 DLL.
For the Java part, you might do the process execution or use one of the Java - .NET bridges that exist out there.
Just some other suggestions to consider.
|
|
|
|
|
I would like to display a text status in MFC main frame from anywhere from my code.
I am using standard MFC CStatusBar indicators
static UINT indicators[] =
{
ID_SEPARATOR, // status line indicator
ID_STATUS_00,
ID_INDICATOR_CAPS,
ID_INDICATOR_NUM,
ID_INDICATOR_SCRL,
};
and in main frame message map
ON_UPDATE_COMMAND_UI_RANGE(ID_STATUS_00,ID_STATUS_99, OnUpdateRange)
The processing function is defined , per MSDN
void CMainFrame::OnUpdateRange(CCmdUI *pCmdUI)
When I test post the last message in range
PostMessage(ID_STATUS_99);
the OnUpdateRange gets executed , however, I do not know how to retrieve the correct range message from CcmdUI.
Any help will be greatly appreciated.
Cheers Vaclav
|
|
|
|
|
pCmdUI->m_nID will give you the ID
|
|
|
|
|
That is what I thought ( found in documentation) , but it is always the ID of the first message in range.
What is odd - the ON_UPDATE_COMMAND_UI_RANGE function gets executed initially and so far I do not know why.
As long as this is how it suppose to work I'll just keep on debugging to find out what I missed.
Thanks for your help.
|
|
|
|
|
Vaclav_Sal wrote: PostMessage(ID_STATUS_99);
Should that not be
PostMessage (WM_COMMAND, ID_STATUS_99) ?
I presume that you are updating some sort of progress report, in which case I'd recommend just posting a registered window message to your main frame, and letting a message handler there deal with it, rather than handling 100 different messages.
ie:
PostMessage (CMainFrame::g_rwm_UpdateStatus, nProgress, nProgressMax);
CMainFrame
{
....
static UINT g_rwm_UpdateStatus;
...
UINT CMainFrame::g_rwm_UpdateStatus = ::RegisterWindowsMessage (_T("CMainFrame::g_rwm_UpdateStatus"));
...
ON_REGISTERED_MESSAGE(g_rwm_UpdateStatus, OnUpdateStatus)
...
and so on. You don't have to have the message number in the header - you can have many calls to RegisterWindowsMessage in many parts of your code, you just have to use the same string name each time. I use the class/member variable, but you could also use a GUID. Just make sure to comment for your future self.
In another note, when you're debugging Update handler, you can always walk up the call stack to see why you're getting parameters that you do.
Good luck,
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
Thanks Iain.
It just bugged me, I kept thinking there got to be some “index” somewhere to keep track of the range.
So – I made three major mistakes -
I have no clue why I thought PostMessage(ID_whatever) would work.
Second mistake and third – I thought the the MFC will route the message thru main frame first.
So if I do PostMessage(WM_COMMAND, ID_STATUS_99) it works only when posted in main frame.
I'll admit – most of the time I just do not understand how MFC routes the messages!
In this “case” I have a Cview in splitter and maybe that is the “problem”.
I guess I need to look it up somewhere , again!
I was planning to have the actual text in the function which updates the status text.
Anyway – I'll take a look at registered message as you suggested.
Cheers
Vaclav
In the mean time I cheated this way
AfxGetMainWnd()->PostMessage(WM_COMMAND ,ID_STATUS_99);
but there is still a problem - the status update is called when anything is updated ( duh) and the text goes back to the first index in range.
Working on that. Perhaps static text variable will do.
-- modified 24-Jan-13 11:47am.
|
|
|
|
|
I would recommend against using WM_COMMAND for your status update message, and go for the registered window message:
1/ It saves command collision
2/ MFC does a LOT of work routing command messages about. This is one of its great strengths, and makes many things nice and elegant, but it can be confusing too.
3/ As long as you use the same string id for the message, you don't have to share header files, making code independence a bit cleaner.
Doing AfxGetMainWnd()->PostMessage is not cheating at all! Just change from WM_COMMAND and I'll be happy with you.
As you why the status bit is being reset? No idea, that will depend on the details of your code. I bet your command handler is being called from places you didn't expect. (See point 1 above).
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
I wrote one application. The main frame is a form without border. So it donot have the task bar mouse click function. The first mouse click on the application icon in the task bar, the application will hide. The second mouse click, this application will show.
After I debug in the OnActiveApp, I find that sometime one OnActiveApp called, the other two OnActiveApp called when use mouse click the taskbar icon. How to filter the useless OnActiveApp event?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
