|
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
|
|
|
|
|
Or better yet, use
int nStrings = -1;
std::vector<CString*> pszStrings;
then for each new string:
{
nStrings++;
pszStrings->push_back(new CString);
pszStrings[nStrings]->Format("%s",YourStringToSet);
}
- Nitron
"Those that say a task is impossible shouldn't interrupt the ones who are doing it." - Chinese Proverb
|
|
|
|
|
AS has been said, you should use vector. I'd also use iostreams, then if you use std::string it's as easy as using getline to read in the strings, none of this stuffing around with C.
Christian
No offense, but I don't really want to encourage the creation of another VB developer. - Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael P Butler 05-12-2002
Again, you can screw up a C/C++ program just as easily as a VB program. OK, maybe not as easily, but it's certainly doable. - Jamie Nordmeyer - 15-Nov-2002
|
|
|
|
|
There is no reason not to use MFC. The problem lies with the stringArrayPath.SetAt(...); you have not preallocated the size of the array and should have used stringArrayPath.SetAtGrow().
First, though, drop the fopen and use the CStdioFile class.
For the loop, simply use:
<br />
CString str;<br />
<br />
while (file.GetString(str))<br />
{<br />
<br />
stringArrayPath.Add(str);
<br />
stringArrayPath.SetAtGrow(entry, str);<br />
}<br />
<br />
|
|
|
|
|
I'm getting an error error 1063 in StartServiceCtrlDispatcher.
Can someone tell me what this is?
Also, how do I get a description for error 1063?
Thanks,
Maloo
|
|
|
|
|
In Visual Studio 6.0:
Menu: Tools->Error Lookup
Enter the number then Lookup
1063 = "The service process could not connect to the service controller. "
Try a search on Google Groups: there are a few threads that reference this issue.
Debbie
|
|
|
|
|