|
where is this OnInitialUpdate
sorry am new to MFC.
|
|
|
|
|
I did that man. here is the problem
first if i get rid of the startup child form, the CGUIView OnInitialUpdate does not even get called, so that code do nothing.
Second i have no idea how to use SendMessage
but this is what i did:
void CQCProGUIView::OnInitialUpdate( )
{
LoadLaunchBar( );
}
int CQCProGUIView::LoadLaunchBar( )
{
m_launchbar = new CLaunchBar( );
m_launchbar->DoModal( );
return 0;
}
now this what this does is basically the application runs, but i don't seee anything at all( not even main MDi form ).
if i replace that with:
m_launchbar->ShowWindow( SW_NORMAL);
the following assertion fails:
BOOL CWnd::ShowWindow(int nCmdShow)
{
ASSERT(::IsWindow(m_hWnd) || (m_pCtrlSite != NULL));
if (m_pCtrlSite == NULL)
return ::ShowWindow(m_hWnd, nCmdShow);
else
return m_pCtrlSite->ShowWindow(nCmdShow);
}
|
|
|
|
|
Hi,
Add cmdInfo.m_nShellCommand =CCommandLineInfo::FileNothing;
in Initinstance().
Bye,
Cool Ju 
Dream Ur Destiny
|
|
|
|
|
hey thanks cool ju, that FileNothign worked like a charm.
am still trying to show up the dialog thou
|
|
|
|
|
Hi,
Instead of Dialog use a DialogBar which can be docked like a toolbar. Create the dialog bar in MainFrm::OnCreate() function and dock it where ever you want.
Adios,
Cool Ju
Dream Ur Destiny
|
|
|
|
|
how do you dock, actually I am using a dialog bar
I thoguht docking was not possible , so i was doign poisitioning and sizing myself.\
how would you suggest I try docking?
|
|
|
|
|
Hi,
You have to the dock the dialogbar using SetWindowPos() function.
I suggest you to do in MainFrm class not in View class.
Insert a dialog and change the style to child.
Declare a CDialogbar object(eg: m_dlgbar) in MainFrm.h
In MainFrm::OnCreate funtion
m_dlgBar.Create(this, Id of the dialog template,CBRS_LEFT|CBRS_TOOLTIPS|CBRS_FLYBY,id of the dialog template);
m_dlgBar.SetWindowPos(&m_wndStatusBar, x,y,cx,cy,SWP_NOSIZE|SWP_NOMOVE);
Adios,
Cool Ju
Dream Ur Destiny
|
|
|
|
|
A couple fo things:
1. The object was a CDialog so I changed the base class to CDialogBar
2.I used following code
m_launchbar->Create( this,IDD_LAUNCHBAR,CBRS_BOTTOM ,IDD_LAUNCHBAR );
this docs the window fine at the bottom without any setting of position and size using the SetWindowPos.
Now what happens is every button on the dialogbar is disabled and it took away the WinXp kind of look from the buttons too!!!
Any ideas, am reading MSDN too on this.
Thanks for your help , it was awesome
|
|
|
|
|
I have a code base that can produce two separate programs with different functionality. This functionality is controlled via #defines in the main code. I would like to use the same #define to control the program’s icon, and the wording in a few menus. I found that the following code will allow me to control the icon:
<br />
#if defined(APSTUDIO_INVOKED)<br />
IDR_MAINFRAME ICON "..\\res\\MAIN.ico"<br />
#else<br />
#if defined(MAIN_PROG)<br />
IDR_MAINFRAME ICON "..\\res\\MAIN.ico"<br />
#else<br />
IDR_MAINFRAME ICON "..\\res\\SECONDARY.ico"<br />
#endif<br />
#endif<br />
The problem is that as soon as someone actually edits a file with the resource editor, all of the conditional code is removed.
Is it actually possible to conditionally change the icon of a program, and if so what is the recommended method. I’m trying to avoid going to multiple rc files, since we will have to keep them in sync from this point on.
|
|
|
|
|
Yeah, I've noticed that in MSVC6. Bloody annoying and bloody stupid of Microsoft.
Steve
|
|
|
|
|
An RC File is Automatically maintained by the MFC Editor. That's the whole Idea behind IDE, and ofcourse it will wipe it.This is an MFC Feature since the days of Windows 3.1, and NOT a feature of MFC 6.0(or earlier or later) If you want resource code, not edited by the IDE, handwrite it in the .RES File (which is a Text File Similar to the RC File) found in your resource directory(underneath Debug and Release)
Tip, If you do not know the Syntax, create it first in the Resource Editor, then copy the entire text to the .Res File, and then delete the item from your resource editor window. It will still be in the res File, The Resource Editor does no know about that File and will leave it alone)
regards
LateNightsInNewry
|
|
|
|
|
The whole idea of the IDE is not to destroy information but to make it easier to author/modify it. And it has nothing to do with MFC; it's the resource editor where the fault lies and it manifests itself whether MFC is used or not. I used the word "fault" intentionally because it is a fault: There is nothing to stop the resource editor getting the current defines from the project settings for the currently selected configuration and only editing the relevant subset.
Steve
|
|
|
|
|
LateNightsInNewry wrote: ...the .RES File (which is a Text File Similar to the RC File)...
No it's not. It's a temporary binary file that the resource compiler creates.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
hi,
use CStudioFile Instead of the CFile, because there is One Method called
ReadLine(...) which will solve your problem. also to Read use only
ReadHuge(...).
good luck.
thanks,
uday.
uday kiran
|
|
|
|
|
I think this reply might be in the wrong thread?
Steve
|
|
|
|
|
How about:
IDR_MAINFRAME1 ICON "..\\res\\MAIN.ico"
IDR_MAINFRAME2 ICON "..\\res\\MAIN.ico"
IDR_MAINFRAME3 ICON "..\\res\\SECONDARY.ico"
...
CMyDlg::CProgressTestDlg(CWnd* pParent )
: CDialog(CMyDlg::IDD, pParent)
{
#if defined(APSTUDIO_INVOKED)
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME1);
#elif defined(MAIN_PROG)
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME2);
#else
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME3);
#endif
}
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: How about:
IDR_MAINFRAME1 ICON "..\\res\\MAIN.ico"
IDR_MAINFRAME2 ICON "..\\res\\MAIN.ico"
IDR_MAINFRAME3 ICON "..\\res\\SECONDARY.ico"
...
CMyDlg::CProgressTestDlg(CWnd* pParent /*=NULL*/)
: CDialog(CMyDlg::IDD, pParent)
{
#if defined(APSTUDIO_INVOKED)
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME1);
#elif defined(MAIN_PROG)
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME2);
#else
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME3);
#endif
}
If I'm reading the above correctly, this will cause the program to use the correct icon when it is running, but not when the executable is being displayed in explorer, folder browser, etc. It would appear that windows uses the icon with the lowest ID number for for this.
|
|
|
|
|
How do I forward an API Call from one DLL to the Next, i.e. What is the syntax for writing a .DEF file for MYUSER.DLL, to effect linkage via that to MYPRIVATE.DLL, where the 'Real code' is located
LateNightsInNewry
|
|
|
|
|
Should have been headed as 'Forwarding APIs'
LateNightsInNewry
|
|
|
|
|
hi all,
i've got a quick question about cfile::read. i just need to get each line of a text file in a loop so i can process each line. can someone show me how, or tell me where to look?
thanks in advance,
sam kline
|
|
|
|
|
|
thanks for the tip, i used CStdioFile::ReadString
sam kline
|
|
|
|
|
If you look up the Help Files, you will finf:
CFile::Read
virtual UINT Read( void* lpBuf, UINT nCount );
throw( CFileException );
This will read nCount bytes of raw data from the file object, into your (previously created buffer. I suspect from your question that you already tried this, and somewhere failed to read it back. Easy trap to fall into, takes a bit of history. In the Oldendays, when computers took punchcards, (I punched many a card myself on those rotten noisy machines) a protocol had been established for each computer system, largely and loosely based on the telegraph system. In order to get the machine at the other end of the line to advance to a new line, you had to send two control characters, a Line Feed (LF Char, ASCII 0x0A), to move the Paper forward, and a Carriage Return Char(CR char, ASCII 0x0D)
These could be sent in any order, provided both where sent. You can imagine yourself what would happen if either or both where ommitted, the result I can assure you , was generally not legible.
In came the VDU Display, a forerunner of the screen you are looking at reading this, and everybody took a step back! What should we send at the End of a Line,( the Windows concept that a document could extend beyond the boundaries of a screen was only in it's infancy). The Discussion was: either a Line Feed, or a CR, Or, ignore the new technology, and treath it as a printer, and send it both, or send it another magical incantation, with aq deeper meaning as to how the result was to be displayed on the screen. All this upset took place at the time when Bill Gates was getting together with a couple of friends, to start off a new business venture.Between then and now, learned committees where formed to formulate software standards, and found invariably, that to land on one side of the debate, or on the other, would invalidate either way years of established practice, so, the issue was shied away from. Also, as software developed, it became less important, compiler writers, and library writers adopted a standard, and, as long as one was aware of the problem, it was quite easy to write a small routine to convert from one to the other.
The Weazel code started I think in the ANSI C Library, you open a file as: FILE F =fopen("MyFile.Ext","r+"), and when reading the file thus opened, all twobyte CR-NL chars are converted to a single LF.Conversely, if yoy write a buffer containing a LF, it witt be written to file as a LF-CR combination. This happens automatically, (and as some people would say, underhand). Ofcourse, this sort of modifying things read from, or written to file, would not do if you are reading or writing binary data. To allow for this, the ANSI Standard allows for an alternative way of openeng a file, which will read and write a file exactly as is, without underhand modifications. To get this, you use:
FILE F =fopen("MyFile.Ext","rb+")Note the 'b' for Binary!!
Now, all this is relatively easy to follow, if you have a genuine text file, open it with one of the "r" attributes, if it is Binary, use the "rb" attribute. Strings in memory are always stored with a single CR character to denote a new line.
Bring in MS Wiondows, and its associated text controls, and the confusion is of a babylonian nature again, Some controls expect a single LF char, others expect a single CR, and there are others again who expect both, or attach special meaning to the absence or presence of one or the other. I had to write a number of simple routines to copy a string from one buffer to another, just to suit the case, and in the knowledge that the code would probably need modification to support the next version of MFC. I must admit that Microsoft seems to have been consistent sofar, and very little needed changing. However, it remains a nuisance, and something that can quite easily throw those unaware of this conundrum of the path.
regards
LateNightsInNewry
|
|
|
|
|
hi,
use StdioFile Class for this Approach and use the Method called ReadLine(...)
and if you want to read entire file use ReadHuge(...) instead of Read(...).
cheers,
uday.
uday kiran
|
|
|
|
|
kiran janaswamy wrote: ...if you want to read entire file use ReadHuge(...) instead of Read(...).
These two methods behave the same in Win32 (i.e., Read() can read entire files).
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"There is no death, only a change of worlds." - Native American Proverb
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
