|
|
I am supporting French for my project (MFC).
I have to use "String Tables" instead of creating a new set of Dialogs for each supported language. String Tables are to support multiple languages.
Could you tell me more about this, please.
Please send me an example
Thanks a lot!
Papais
|
|
|
|
|
Start by reading:
1) Internationalization and Multiple Language Support[^]
2) Tips on internationalization of software[^]
Another approach to 1 above would be to have string resource table only DLLs and manually loading strings from resource instead of recreating each dialog, menu, and etc. for each language. This would require more coding, but a non-programmer could be taught to edit the string tables.
There is also a good book offered by Microsoft Press on the subject, version one of that book was in the VC6.0 MSDN help.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
What version of Visual C++ are you using? If you are using VS 2003 or above, the IDE supports Unicode.
Let us not listen to those who think we ought to be angry with our enemies, and who believe this to be great and manly. Nothing is so praiseworthy, nothing so clearly shows a great and noble soul, as clemency and readiness to forgive.
- Marcus Tullius Cicero
|
|
|
|
|
|
I've created my dialog based application in 1600 x 1200 resolution.. It's a pretty large dialog with lots of conrols..
My problem is when the screen is set in lower resolutions, The program will not load the full dialog. Some of the right and bottom gets cut off. I've made it so you can scroll vertically and horizontally, but it still cuts off some of the dialog.
Any Ideas?
http://www.aquawicket.com/edrummonitor
|
|
|
|
|
aquawicket wrote: Any Ideas?
Create various-sized templates and load the appropriate one at runtime.
Program to the smallest common denominator.
Use a property sheet.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
The dialog open fine in 1600x resolution and the I can change the resolution to a lower one while the app is open and still see it all by scrolling.. I've put alot of work into this dialog and just want it to not get cut off in lower resolutions..
I'm not really understanding what is ment by "Program to the smallest common denominator. and Use a property sheet"..
My program is done with visual studio 2005 using MFC.. It works like a charm.. all except this one bug.
|
|
|
|
|
aquawicket wrote: I'm not really understanding what is ment by "Program to the smallest common denominator.
You could have designed your dialog with your screen resolution set to 1024x768.
aquawicket wrote: I'm not really understanding what is ment by Use a property sheet"
Property Sheet[^]
All pain is either severe or slight, if slight, it is easily endured; if severe, it will without doubt be brief.
- Marcus Tullius Cicero
|
|
|
|
|
Hello!
I'm currently teaching myself writing Windows32 applications with C/C++ without MFC.
Currently I'm trying to apply XP visual styles for controls. I tried to learn from the MS Platform SDK documentation how it is done, but unfortunaltely it left me  and quite clueless. Please give me some hints!
Let's assume I have a simple Windows application with one window containing a simple button (a real parent window, not a dialogue - hope I'm using the right terminology here):
#include <windows.h><br />
#include "commctrl.h"<br />
<br />
LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM) ;<br />
<br />
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) {<br />
MSG msg;<br />
WNDCLASS wndclass;<br />
<br />
wndclass.style = CS_HREDRAW | CS_VREDRAW ;<br />
wndclass.lpfnWndProc = WndProc ;<br />
wndclass.cbClsExtra = 0 ;<br />
wndclass.cbWndExtra = 0 ;<br />
wndclass.hInstance = hInstance ;<br />
wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;<br />
wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;<br />
wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;<br />
wndclass.lpszMenuName = NULL ;<br />
wndclass.lpszClassName = TEXT("App");<br />
<br />
if(!RegisterClass(&wndclass)) {<br />
MessageBox (NULL, TEXT("This program requires Windows NT!"), TEXT("App"), MB_ICONERROR);<br />
return 0;<br />
}<br />
<br />
HWND hwnd = CreateWindow(TEXT("App"), TEXT("Just an application"), <br />
WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, <br />
NULL, NULL, hInstance, NULL);<br />
ShowWindow(hwnd, iCmdShow);<br />
UpdateWindow(hwnd) ;<br />
<br />
while(GetMessage(&msg, NULL, 0, 0)) {<br />
TranslateMessage(&msg);<br />
DispatchMessage(&msg);<br />
}<br />
return msg.wParam ;<br />
}<br />
<br />
LRESULT CALLBACK WndProc (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)<br />
{<br />
static HWND hwndButton;<br />
HDC hdc ;<br />
PAINTSTRUCT ps ;<br />
<br />
switch (message)<br />
{<br />
case WM_CREATE :<br />
hwndButton = CreateWindow ( TEXT("button"), <br />
TEXT("Just a button"),<br />
WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON,<br />
20, 20,<br />
130, 50,<br />
hwnd, (HMENU) 0,<br />
((LPCREATESTRUCT) lParam)->hInstance, NULL) ;<br />
return 0 ;<br />
<br />
case WM_PAINT : <br />
hdc = BeginPaint (hwnd, &ps) ;<br />
<br />
EndPaint (hwnd, &ps) ;<br />
return 0 ;<br />
<br />
case WM_DESTROY :<br />
PostQuitMessage (0) ;<br />
return 0 ;<br />
}<br />
return DefWindowProc (hwnd, message, wParam, lParam) ;<br />
}
I have added a manifest to the project ressources as told.
All I want now is to enable this button to use visual styles. Please show me how!
Greetings,
Lamgi-Mari
|
|
|
|
|
|
A long time ago, I needed a way to put information into edit boxes etc. in my MFC dialog applications "on the fly". That is, I didn't want to wait till a function terminated and the particular window was updated/repainted. I wanted to see the data change real time as it was running. I didn't want to use a timer so I came up with the following function.
void DisplayNow(int nID, LPCTSTR lpszString)<br />
{<br />
CWnd* pDISPLAY_Wnd = GetDlgItem(nID);<br />
<br />
pDISPLAY_Wnd->SetWindowText(lpszString);<br />
pDISPLAY_Wnd->UpdateWindow();<br />
}
where nID is the ID of the edit box etc. that I want to display the data in
I overloaded more versions of the same functions for integers, floats etc. I am only showing the version that does strings here.
Anyways these functions have allowed me to display data on the fly and I have been quite happy with them for quite some time now.
But, anytime I want to use them, I have to copy/paste them into the application's dialog file. At one point, I tried to wrap them in a class and use them that way but the compiler burped hard at that because the handle to the window (pDISPLAY_Wnd) is not known at compile/link time. So I continued copy/pasting.
Recently I tried to put all the functions into a file called DisplayNow.cpp and DisplayNow.h hoping that, even though I couldn't make them into a class, this would prevent me from the copy/paste thing.
So DisplayNow.cpp looks like this:
#include "stdafx.h"<br />
#include "DisplayNow.h"<br />
<br />
void DisplayNow(int nID, LPCTSTR lpszString)<br />
{<br />
CWnd* pDISPLAY_Wnd = GetDlgItem(nID);<br />
<br />
pDISPLAY_Wnd->SetWindowText(lpszString);<br />
pDISPLAY_Wnd->UpdateWindow();<br />
}
and DisplayNow.h looks like this:
void DisplayNow(int nID, LPCTSTR lpszString);
Now, when I try to compile, I get this error:
DisplayNow.cpp(6) : error C2660: 'GetDlgItem' : function does not take 1 parameters
Am I destined to being forced to copy/paste all these functions into very new application that I create????
Thank you in advance
Pierre
|
|
|
|
|
What if you make a common base class and derive your dialog classes from it - something like:
class CMyDialog : public CDialog
{
public:
CMyDialog() : CDialog() {}
explicit CMyDialog(LPCTSTR lpszTemplateName, CWnd* pParentWnd = NULL) :
CDialog(lpszTemplateName, pParentWnd) {}
explicit CMyDialog(UINT nIDTemplate, CWnd* pParentWnd = NULL) :
CDialog(nIDTemplate, pParentWnd) {}
void DisplayNow(int, LPCTSTR);
};
...
void CMyDialog::DisplayNow(int nID, LPCTSTR lpszString)
{
CWnd* pDISPLAY_Wnd = GetDlgItem(nID);
if (pDISPLAY_Wnd)
{
pDISPLAY_Wnd->SetWindowText(lpszString);
pDISPLAY_Wnd->UpdateWindow();
}
}
-- modified at 18:39 Friday 23rd February, 2007
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
As Mark said, or you could just add a third parameter to the DisplayNow function
void DisplayNow(CWnd *pParent, int nID, LPCTSTR lpszString)
{
CWnd *pDISPLAY_Wnd = pParent->GetDlgItem(nID);
...
}
And in dialog you call it like this:
DisplayNow(this, ID, _T("Text"));
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
pblais wrote: Tired of copy/pasting code
Here is some food for thought Avoiding GetDlgItem
By Joseph M. Newcomer. [^]
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
I know ActiveX methods can return complex data types like structures or classes,I just can't quite figure out how.... For example, I have a class containing 4 data elements (strings) and 4 functions acting as getters... I want to return the class through a method call in my activex ctrl.
From what I've read, I beleive I can do it via IDispatch and a definition in the IDL file, or by returning a VARIANT...
Can someone please point me to a tutorial or article that could help me figure this out?
Thanks in advance!
|
|
|
|
|
I have three questions?
ONE: It is said "using references is safer than using pointer."
Why?
TWO: If I want node objects in heap, how can I assign the pointers from heap memory?
example code)
Node& Nodes[100];
? = new Node();
THREE: Is using pointers faster than using references?
Thanks!
Yonggoo N
|
|
|
|
|
Yonggoo wrote: using references is safer than using pointer
Because a pointer can be NULL. A reference means the object has to exist (of course, that object may not be fully initialized, but it does mean you don't have to worry about a NULL pointer.)
I don't understand what you are doing with two. Node* pNode = new Node; Don't know what the references line has to do with anything.
Yonggoo wrote: Is using pointers faster than using references?
With an optimizing compiler the performance is generally the same since internally references are pointers.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Is this code OK!
Node* Nodes[101];
refNodes& getNodes()
{
for(int i=1;i<=100; ++i)
{
Nodes[i] = new Node();
}
return Nodes;
}
Thanks!
Yonggoo
|
|
|
|
|
Yes, but you've failed to initialize Nodes[0]. The preferred style is:
for (int i = 0; i < 101; ++i)
...
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
No, since you can't convert Node*[101] to Node&.
You could return Nodes[101] as a Node**. I'm not sure how you would return it as a reference or why you would bother.
Anyone who thinks he has a better idea of what's good for people than people do is a swine.
- P.J. O'Rourke
|
|
|
|
|
Joe Woodbury wrote: Because a pointer can be NULL. A reference means the object has to exist (of course, that object may not be fully initialized, but it does mean you don't have to worry about a NULL pointer.)
That is a red herring...
struct A {
int a;
};
void func1(A& r)
{
printf("r.a = %d\n", r.a);
}
void func2(A* p)
{
func(*p);
}
...
A* p = 0;
func2(p);Guess where it'll blow up on you in virtually all C++ compilers? References in C++ are not safer than pointers. It's just an illusion...
|
|
|
|
|
Joergen Sigvardsson wrote: void func2(A* p)
{
func(*p);
}
The only reason it blows up is because you are dereferencing a NULL pointer, not because references are not safe. And one wonders why so many products have stupid warning labels; to prevent them from being used in ways they were not intended to be used.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
PJ Arends wrote: The only reason it blows up is because you are dereferencing a NULL pointer, not because references are not safe.
My point is that you can't trust a reference to be always valid, as many people suggest.
--
Fun for the whole family - except grandma and grandpa
|
|
|
|
|
Yonggoo wrote: Node& Nodes[100];
? = new Node();
I don't think you can have an array of references
Yonggoo wrote: Node* Nodes[101];
refNodes& getNodes()
{
for(int i=1;i<=100; ++i)
{
Nodes[i] = new Node();
}
return Nodes;
}
return Nodes; is returning a Node**. Is that what a refNodes& is?
Mark
"Do you know what it's like to fall in the mud and get kicked... in the head... with an iron boot?
Of course you don't, no one does. It never happens. It's a dumb question... skip it."
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
