|
Thanks for the answer.
Is it possible however the dialogs to appear in Greek even if the user has the English version of Windows (I am sure this can be done somehow since MS Office (Greek) does it irrespectively of the Windows version, but I do not know how)
Dionysios photeinos@lfme.chemeng.upatras.gr
|
|
|
|
|
You need to change the regional and/or locale settings for the user.
( look in the "Regional Options" control panel. )
Max.
|
|
|
|
|
Has anyone ever programmed an application using a project/workspace model. I am writing an MFC / MDI applicaiton and I need to replicate the same idea that VS uses. The user will be working with a collection of documents. Are there any articles / tutorials that anyone knows of?
Ryan Baillargeon
|
|
|
|
|
Ryan B. wrote:
ever programmed an application using a project/workspace model
Yes, I'm currently doing this.- The app I'm working on consumes XML files. The "project" file is just another XML file that refers to the files in the project, as well as some project-wide properties. I use Xerces to parse XML.
- But you don't have to do this using XML - a simple approach is to use .INI files that basically do the same thing.
- A third approach is to represent the "project" object using a binary format that's serialized by your app. This is the least user-friendly way to represent a project but may be appropriate for your app.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
What's the problem? Create CProjectDoc class derived from CDocument, create CProjectDocTemplate from CDocTemplate. The document tree is your project view. Then you are creating some interface for you class, something likes as
void AddToProject(LPCTSTR szFileName)
void RemoveFromProject(LPCTSTR szFile) and etc.
The project is a simplest type of document I have ever seen.
Then, workspace's scheme: If you want use same tree for all open projects, you must refuse to use view in CProjectDoc. Point to MFC that you document has no any views
void CProjectDocTemplate::InitialUpdateFrame(CFrameWnd* pFrame, CDocument* pDoc,BOOL bMakeVisible)
{
pFrame->DestroyWindow();
}
and create separate window (of course, docked  to a hair's breadth as microsoft - chief of fashion) and scan all projects and show their contents as you wish.
I had once similar project and i don't mind to share it with you, but it is simpler to make it on its own than to ransack some thousands lines of foreign code
|
|
|
|
|
The confusing part for me is that this is my first Document/View application and I am working from limited resources.
Your suggestions are very helpful and I was already heading in that direction. Thank you.
Ryan Baillargeon
Software Specialist
Fuel Cell Technologies Inc.
|
|
|
|
|
How to compress some files in a only one ZIP, TAR, ... file ?
Someone knows any function or method ?
Thanks,
Cris.
|
|
|
|
|
|
Also try searching for ZipArchive in the articles. There's a nice library there that takes only a few function calls to compress files into a zip file.
|
|
|
|
|
My initial problem:
I have a UNICODE application, it works fine in Windows
NT/2000, but I need it in Windows 95-98.
I'm trying to use MSLU in Windows95, but it doesn't work.
The problem seem to be with common controls (CEdit, CComboBox...) & menus (saved in my resource .rc file
like UNICODE)... all strings are shown like "____"
Somebody told to me: "Handle the WM_NOTIFYFORMAT message and return
NFR_UNICODE"
So, I tried to handle that message like this:
LRESULT CConnectorDlg::OnNotifyFormat(WPARAM wParam,
LPARAM lParam)
{
return NFR_UNICODE;
}
and in message map:
ON_MESSAGE(WM_NOTIFYFORMAT, OnNotifyFormat)
but my function never is called.
So, I tried too:
LRESULT CConnectorDlg::DefWindowProc(UINT message, WPARAM
wParam, LPARAM lParam)
{
if (message == WM_NOTIFYFORMAT)
return NFR_UNICODE;
return CDialog::DefWindowProc(message, wParam,
lParam);
}
But, common controls still are shown bad...
CConnectorDlg is a CDialog with a combo box and CEdit
Thank you in advance for your time.
Up the irons!
|
|
|
|
|
I'm trying to convert unicode (obtained from a file) into something readable.
i tried W2A and W2T but with no avail
|
|
|
|
|
Is it for debugging? If so:
VC++ 6.0:
Tool | Options, Debug tab, check the Display unicode strings check box
VC++ 7.0: Automatic
If it is not for debugging, could you please show some code? Also, the X2CX macros need the USES_CONVERSION declaration to work.
Michel
It is a lovely language, but it takes a very long time to say anything in it, because we do not say anything in it, unless it is worth taking a very long time to say, and to listen to.
- TreeBeard
|
|
|
|
|
Hello All.
I'm working on an application using Doc/View. I was using SDI to create my application but I really need to display multiple views of a single document. I'm using splitter windows to divi up my views. Even though I am using multiple views, there is one view that will always be displayed when a document is open, so I have associated that View with the document.
My question is, Can I easily just use these other views against the document, and just get access to the document through the single associated view???
Thanks
|
|
|
|
|
What you want is multiple views with a single document...
Just create document templaes for each view, and associate the same document class to each template.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
So what you mean is this:
CSingleDocTemplate* pDocTemplate;
pDocTemplate = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTheDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CView1));
AddDocTemplate(pDocTemplate);
CSingleDocTemplate* pDocTemplate2;
pDocTemplate2 = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTheDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CView2));
AddDocTemplate(pDocTemplate2);
CSingleDocTemplate* pDocTemplate3;
pDocTemplate3 = new CSingleDocTemplate(
IDR_MAINFRAME,
RUNTIME_CLASS(CTheDoc),
RUNTIME_CLASS(CMainFrame), // main SDI frame window
RUNTIME_CLASS(CView3));
AddDocTemplate(pDocTemplate3);
If I'm understanding correctly. But in this case, are the document views all being associated with the same Document instance? If this is the case, do you know why this occurrs?
This being the case, in each individual view class I should be able to perform this:
CCalibrationDoc *pDoc = this->GetDocument();
pDoc->GetSomeDataStuff(...);
And they all should return the same data from that single instance of the Document Object.
Based on this info I should also be able to set data in the document object as well right? If so, does the frame work handle any possible thread lock issues that could occur?
Thank you very much. I appreciate it greatly. There is VERY little internal help available for me. Actually, there is none and I'm on my own, so I appreciate it alot.
Dan
|
|
|
|
|
I don't understand what is happening here.
Anyone able to elucidate?
I have a full screen window. (a vanilla
CWnd derivative) This works fine. It covers
the task bar and all ok. The problem comes
when it creates a full screen modal dialog.
That dialog assumes full screen in OnInitDialog
(via SetWindowPos).
The problem is that where the task bar
would have been shown, had this not been a full
screen window, the parent window shows through
instead!
I have worked around the problem, by hiding the
parent window. But I'd really like to know what
is going on here.
..especially why the work around of hiding the
parent window should fix it!
|
|
|
|
|
Without playing around with this, I suspect that you'd have to override the OnSize() method for the dialog's CWnd. The original is probably taking into account the size of the taskbar. That's the first place I would look.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
I check the size of the window in OnPaint. The dialog
is sized as it should be-- full screen. It paints that
region where the parent shows through as well. It's as
if the parent window were made up of two parts, with
the region where the taskbar would have been, behaving
as if it were topmost. Most strange-- enough that I
suspect some unknown OS behavior or a bug.
(I'm running on XP here.)
|
|
|
|
|
I see this same problem. I am creating a full screen borderless window with flags TOPMOST for my screen saver window. On Windows 98 when I call the password verification dialog, the dialog only sometimes draws above the screen saver window. MS screen savers work fine, but they must be doing some magic thing to get theirs to work? I have tried several things, none of which seem to work including:
1) Setting my full screen window to the bottom of the Z order.
2) Creating the dialog in another thread.
3) Disabling the full screen window painting when the dialog is active, thinking it might be painting over the dialog.
But none of these things seem to work, any ideas here, I imagine it might be the same problem as Scott H. Settlemier is having.
Stop playing AC2 and please help us oh great Win32 gurus...
|
|
|
|
|
I've had your same problem last week...
It's due to the system workarea.
You must resize the workarea at the beggining of your app. and resize again at the end of your app.
here's the code:
<br />
CRect rectWorkArea;<br />
<br />
rectWorkArea.left = 0;<br />
rectWorkArea.top = 0;<br />
rectWorkArea.right = ::GetSystemMetrics(SM_CXSCREEN);<br />
rectWorkArea.bottom = ::GetSystemMetrics(SM_CYSCREEN);<br />
<br />
SystemParametersInfo(SPI_SETWORKAREA,0,&rectWorkArea,SPIF_SENDCHANGE);<br />
then you can resize your dialogs and windows as always...
NOTE:
I had to resize the windows using this:
<br />
this->SetWindowPos(&wndTopMost,0,0,::GetSystemMetrics(SM_CXSCREEN),::GetSystemMetrics(SM_CYSCREEN),SWP_SHOWWINDOW);<br />
TopMostFlag is an option...
this had to be done in order to avoid flickering when I used the common way of resizing...
Hope this helps...
|
|
|
|
|
NEW INFO:
I checked the clip box in OnPaint. It was
0,30 to 1024,768!!! But the area showing
through was at the bottom. It looked like
the window had been somehow moved from
where I set it with SetWindowPos. So I
checked the window rect and the window
was now 0,-30 to 1024,738!! I had set the
coordinates to 0,0 to 1024,768.
The SetWindowPos call did not use SWP_SHOWWINDOW
since I wanted to wait until all of my initialization
had completed in OnInitDialog. When I added
SWP_SHOWWINDOW, the problem cleared up.
So it looks to me that there may indeed be a Windows
bug here. Something shifted my window up, just
the amount that is the size of the taskbar.
If I place the taskbar to the side, the window will
get shifted to the side.
Very perplexing...
Any clues as to what is happening?
|
|
|
|
|
That is most likely the task bar shifting the window about. The taskbar must always be visable and will move windows accordingly if they get in the way. Try setting the taskbar to 'AutoHide' then see if you have these same issues, I bet you won't. But I wonder if the taskbar should even be moving your window since you are manually forcing it be fullscreen, I would think the taskbar should only move windows that are maximized, not that set the window position and size directly.
|
|
|
|
|
Right, I don't think anyone should be moving the window
after I have set its position. It is not a maximized window,
merely a full screen window. That the problem does not occur
if I pass SWP_SHOWWINDOW in the call to SetWindowPos, makes
me suspect that this is not just unexpected behavior, but
a bug. (after all, it shouldn't matter a lick to the OS
whether the window has been painted already or not!)
|
|
|
|
|
I am opening a text file with fopen. I can read in text strings and assign them to a CString. I am trying to set the CString in a CStringArray for later use but the computer doesn't like it.
CString s;
FILE *pSkinfile = fopen ((LPCTSTR) lpFileName2, "rt");
if (!pSkinfile)
{
return false;
}
do
{
fgets (szLine, 256, pSkinfile);
for(zero = 0; zero < numSurf; zero++)
{
match = strncmp (szLine, stringArraySurfaces.GetAt(ij), n_lengthArray[ij]);
if(match == 0)
{
sscanf (szLine, "%s", S1);
->This line screws it up stringArrayPath.SetAt(ij,S1);
}
ij++;
}
ij = 0;
}while(feof(pSkinfile) == 0);
fclose (pSkinfile);
Is this because I'm reading in a stream and can't output to a variable?
|
|
|
|
|
You didn't say what the error was, so I may be way off base. Did you set the size of stringArrayPath using SetSize. The SetAt function will not grow the array, so you need to be sure you are writting to a valid location. You should either set the size of the array or use the SetAtGrow function or the Add function.
Gary Kirkham
A working Program is one that has only unobserved bugs
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
