|
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
|
|
|
|
|
I want to encrypt a string using MS Crypto API on Windows XP and decrypt it on Win XP OR on Win 2000. I have encrypt and decrypt code working on XP but the decrypt returns garbage on Win 2000.
I think that this is because the string was encrypted with Strong RSA, which is the default on XP, but W2K (without high security pack) does not support strong RSA. So how do I tell XP to encrypt using standard RSA, or RSA that is supported by W2K ? I have looked at the other provider types but they appear to be subsets of PROV_RSA_FULL and I'm not sure if they will work with W2K either.
The code I'm using is pretty standard:
CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, 0);
CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash);
|
|
|
|
|
All the samples in MSDN uses PROV_RSA_FULL, and it says on the bottom that it is supported by W2K. i've worked before with PROV_RSA_FULL, and I haven't encountered with any problems what so ever...
maybe something you do is wrong?
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
Yes PROV_RSA_FULL is supported on W2K. But there were changes to the default encryption method in XP. XP now uses Strong RSA encryption and 128 bit key length. Windows 2000 used (Not Strong) RSA encryption and 40 bit key length.
The string is encrypted on XP but needs to be decrypted on Windows 2000. W2K will try to decrypt using PROV_RSA_FULL but only using a 40 bit key and this is why it fails.
Does anyone know how to force the Crypto API to use standard (NOT Strong) encryption and 40 bit encryption?
Thanks
|
|
|
|
|
Hi All
I have a property page with a tabbed property sheet, which works fine but im a bit stuck on how you get
the values back from each of the property sheets
property sheet is based on the CPropertySheet class, which is not based on CDialog but it provides the same functionality as a dialog.
i wanted to do something like the below, but when ok is called m_c_check doesnt have a value
can anyone point me in the right direction
CEmplSheet EmpSheet("Employment Application");
CEmploymentDlg Empl;
CExperienceDlg Exp;
CEducationDlg Educ;
EmpSheet.AddPage(&Empl);
EmpSheet.AddPage(&Exp);
EmpSheet.AddPage(&Educ);
EmpSheet.EnableStackedTabs(TRUE);
m_pMainWnd = &EmpSheet;
int nResponse = EmpSheet.DoModal();
if (nResponse == IDOK)
{
int i= Educ.m_c_check1.GetCheck();
}
else if (nResponse == IDCANCEL)
{
}
|
|
|
|
|
in most cases property pages reside in the property sheet class
Kuphryn
|
|
|
|
|
thanks for the reply,
but if your not going to be helpful is there any point
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
