You can use CWnd::EnableWindow() to enable/disable buttons... you should however, do this from within the class (i.e. an external class should probably not be controlling buttons on a different class directly). So you can maybe set a control variable in when you create the dialog class so that you can handle the enabling/disabling OnInitDialog() (the proper place to initialize GUI components).
It's impossible to give an answer to such questions in a technical forum. You need to analyse your requirements and figure out how you wish to represent the data in your charts. The chances are that you will be drawing lines and blocks so the GDI+[^] classes will probably be of some use.
I want to develop an application with MFC,which has similar functions to Gantt
I am assuming you have 3-4 yrs of development experience in MFC. if you want to develop your own charting control, you can go through GDi and GDI+ classes, which provide you low level access to window graphics.
Otherwise google is always your good friends for developer!
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow Never mind - my own stupidity is the source of every "problem" - Mixture
In my program I have a MainThread and more WorkerThread. Suppose that at certain event (which I'll manage) the MainTh must send a string (char ) to all WorkerTh, which will then process the request and send a response to MainTh.
What methods provided by windows are more suitable to handle a similar thing?
I'm using multiple document types (e.g. *.txt, *.xml) in a SDI type application, with two CSingleDocTemplate objects that handles two different file formats. The view class is the same for both document templates. However, when opening a file of the type that isn't currently open, MFC creates a new top level frame instead of disposing of the old view. This happens in CSingleDocTemplate::OpenDocumentFile, but I'm not that happy about overriding stuff about the view/doc logic of MFC.
What I want is to keep the same frame for both document types, but from what I can read in the MFC source, the framework isn't really designed for that behaviour.
i have an MFC c++ application build with /clr option and have integrated crash reporting feature.
the crash dump it generates does not show line numbers when i debug the dump using windbg.
(i found that applications build with clr does not show line numbers)
it shows the function name where it crashed but not the exact line number. for eg
03434456 02312434 CExApp::OnOpenFile() + 0x30c
whats 0x30c ? is it an offset in the function?
Is there any way to calculate the line number by using 0x30c ?
int tr = 0;
int rows = 256;
int ms = 3;
tr += (rows & (1 << (ms - 1))) << (ms - 1);
tr = rows & (~(1 << ms));
in above program have used only 3 integers...so can we consider that this program's memory requirement will be 3 integers (3*4 bytes).
or the compiler will generate some intermediate integers for storing values of expressions like
(~(1 << ms)) etc... and thus the memory requirements of this program will be more than 3 integers.
i know it all depends upon how the compiler generates the code.
but wanted to know the relation (w.r.t memory) between the variables declared and the intermediate expressions.
Or you may please direct me to appropriate resources (forums, links)for this..
If you are using Visual Studio then you have the opportunity to see the disassembly listing (for instance via the debugger or the /FA compiler option). Other compilers may provide you this facility as well.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
It depends on the compiler, and the switch settings you apply.
A smart compiler may toss it all out as all calculations ultimately generate a value for tr which is then not used at all.
And if you were to add a function call (say print(tr);) which makes the calculations necessary, the compiler could still discover that the tr value is a constant that can be evaluated right away at compile-time, hence tossing the other variables.
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Please use <PRE> tags for code snippets, they improve readability. CP Vanity has been updated to V2.4
In addition to previous replies, since the integers are automatic, i.e. allocated on the stack, which already has storage reserved, the memory footprint will not be affected if you add or remove such local variables, as it does not affect system resources. However, the stack will fill up quicker if you (or the compiler) add them.
All you need to know is unicode.
all the text strings should be converted to unicode format.
make a collection\ identify of all the readable text string on your apps gui.
convert all the char buffers used to process the text strings to wchar buffers (char : 1 bytes and wchar 2:bytes)
MFC CString will automatically behave as unicode when you declare your app as unicode application either by mentioning
in stdafx.h or some global file which is accesible to all the other files.
You may also use app property dialog to declare your app as unicode.
While convering text from ansi to unicode, WideCharToMultiByte and MultiByteToWideChar APIs will be required.
this is just some hints to proceed...you may be required to do other tasks as appropriate depending upon your app.
Internationalisation is a huge topic, but a few pointers:
1. separate all UI strings from your code (string tables are a must in Windows)
2. do localizing into 1 other language in parallel with development to catch problems early
3. use industry standard tools (SDL, memoQ, Idiom, LocStudio if you can find it) for localizing, avoid developing your own tools
4. use the operating systems services whenever possible (NLS functions in Windows)