|
Thank you.I'll read it carefully! 
|
|
|
|
|
Jokcy wrote: I want to develop an application with MFC,which has similar functions to Gantt
chart.
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
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
Support CRY- Child Relief and You
|
|
|
|
|
I am a green hand .Anyway,thank you all the same.I just want to train myself.
|
|
|
|
|
I draw a bitmap in the window client area
case WM_PAINT:
hdc = BeginPaint(hWnd, &ps);
memDC = CreateCompatibleDC(hdc);
SelectObject(memDC,hbmp);
GetObject(bmp, sizeof(bm), &bm);
GetClientRect(hWnd,&rcc);
BitBlt(hdc,
0,0, rcc.right,rcc.bottom,
memDC,
0,0,SRCCOPY);
If the the bitmap is bigger than the client area how can i implement VSCROLL and HSCROLL?
|
|
|
|
|
|
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 usually use messages... SendMessage() and PostMessage() methods, with the latter being most appropriate for unsynchronized communications between threads...
|
|
|
|
|
create event to notify mani thread that someting done .
|
|
|
|
|
Hi all,
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.
Anyone with some experience of this?
|
|
|
|
|
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
it shows:
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 ?
thanks
|
|
|
|
|
|
Hello,
consider the following program
void main()
{
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..
Thanks.
|
|
|
|
|
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
[My articles]
|
|
|
|
|
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.
Luc Pattyn [My Articles] Nil Volentibus Arduum
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.
|
|
|
|
|
Having finally started migrating from VS6->VS2010, we have our first attempt at internationalisation looming.
What is current best practice for foreign language versions of C++ apps? Can anyone speak from experience?
|
|
|
|
|
All you need to know is unicode.
all the text strings should be converted to unicode format.
[1]make a collection\ identify of all the readable text string on your apps gui.
[2]convert all the char buffers used to process the text strings to wchar buffers (char : 1 bytes and wchar 2:bytes)
[3]MFC CString will automatically behave as unicode when you declare your app as unicode application either by mentioning
#define UNICODE
#define _UNICODE
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)
Good luck!
|
|
|
|
|
Thanks for this. We are starting slow, just targeting one other language to start, but obviously we want to set everything up to make adding other languages easier in future.
We'll probably try and make a resource DLL per language. Thanks for the pointers to the tools too - I didn't know such things existed, so will have to look into them.
|
|
|
|
|
"Internationalization" is not simply a matter of understanding character set representations.
Potential issues.
1. Understanding culture differences (do your custom icons represent an obscene gesture?)
2. Correct GUI layout.
3. Grammatically correct dynamic output.
4. Verifying that translated text is actually translated correctly.
5. Laws/legal matters that dictate "correct" representations. An example is that some places dictate the use of specific timezones.
|
|
|
|
|
few additional points.
1) reading style ( right to left or left to right ) most of the is taken care
2) The language script may be same in two different languages but the way its words are interpreted may be different
3) On Windows dialog specially, you have to use different dialog template since the default fonts may not render character of UI in a given language.
We face this problems in past, for Japanese font and we have to create a whole new set of dilaog boxes to maintain same look and feel of application throughout the running lifetime of application.
4) The size of executable.and code base itself, If your code works on special hardware ( like Credit card devices where limited amount of memory is available) This could be a huge problem
HTH
|
|
|
|
|
Abhi Lahare wrote: 1) reading style ( right to left or left to right ) most of the is taken
care
 Tell me about it - we've already had a load of hassles getting Hebrew and Arabbic to work correctly - never mind Chinese 
|
|
|
|
|
as far on windows box, all the arabic strings was acceptable to client. we have other hardware were standard font file did not work as desired and gave us a good amount of trouble. sorry I do not remember the details it was a long back 6 yrs back 
In case of Japanese and Chinese ( in different project ) we build a whole set of dialog boxes with different fonts for once user select the input language.
The default (FONT 8, "MS Sans Serif") for us do not rendered the Japanese character.
HTH
|
|
|
|
|
I have created list of points.
CList<CPoint, CPoint> m_PointList;
m_PointList contains the coordinates from the screen display.
I want to find the Right most top point from the list.
For e.g List contains following points:
1)(1263,643)
2)(1258,276)
3)(1225,266)
4)(1180,257)
5)(990,241)
6)(835,239)
7)(935,705)
8)(1094,691)
9)(1258,655)
Please consider the screen coordinate system. i.e X increases from left to right and Y increase from top to bottom.
With the above input points, the output of the program should be (1258,276).
In the above mentioned points the right most point is 1263 but the corresponding y co-ordinate is 643, which is greater than the 2nd point's y co-ordinate for which the x co-ordinate is 1258.
Hence as per the display, the right most top point is (1258,643).
Please suggest the algorithm to be used.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
