|
the thing is, those are calculated ahead of the actual processing, and don't change. the actual work is pretty much 4x the loop i posted.
|
|
|
|
|
Hello. I'm writing some C code for an embedded application, and I've run into a problem wherein a compare against an enumerated value is not being executed correctly. Take the following code snippet, for example:
typedef unsigned int UINT16;
typedef enum enum_items_tag
{
ITEM_1,
ITEM_2,
ITEM_3,
ITEM_918,
MAX_ENUM_ITEMS
} enum_items_t;
UINT16 n;
for ( n = 0; n < MAX_ENUM_ITEMS; n++ )
{
}
The code executes as expected, until n is incremented to equal MAX_ENUM_ITEMS, at which time the compare fails, and execution continues within the loop (when it should have exited). I've done things like this in the past without any problems.
I've tried re-typing n as enum_items_t (i.e. declaring n as "enum_items_t n"), as well as type casting MAX_ENUM_ITEMS as UINT16. The only other thing I can think of at this point is that maybe there is an issue with the number of items there are in my enumerated type (919). Does anyone know if there are such constraints on enumerated types? I'm using a GCC based compiler. Or, if you have any other ideas, it would be much appreciated. Thanks.
|
|
|
|
|
why do not output value of MAX_ENUM_ITEMS to see what it is, you may miss some thing in the middle of the enum.
totally 919 items? MAX_ENUM_ITEMS should be 918.
|
|
|
|
|
You're right. Good catch! The enumerated type enum_items_t has a total of 920 items, including MAX_ENUM_ITEMS. I was thinking in terms of offset, or what n would be as the loop repeats.
Unfortunately, outputting constants information with embedded programming can be a little tricky, especially when you're stuck using a ***** compiler/IDE. I'll see what I can do, though. Thanks.
|
|
|
|
|
Just curiosity: what is the usefulness of such a enum ?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
It's used for quickly indexing into an array, rather than having to use processor time to search for an element.
|
|
|
|
|
Well, I cannot see any speed advantage. Would you please elaborate a bit?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I found the problem. As usual, it turned out to be really simple. My INVALID_ITEM item was positioned at the beginning of the enumeration. When I moved it to the end, after MAX_ENUM_ITEMS, things lined up and started working.
|
|
|
|
|
I did a test for size change of MFC exe.
When a line of code or a small resource bitmap is deleted or added in the exe program, exe size keeps unchanged.
So I guess exe is aligned in size - similar to class aligned in size by its members.
Do you think it is correct or have more info about this?
|
|
|
|
|
Yes. By default applications are aligned on 512 byte boundaries. (Due to a quirk in the Windows 98 paging mechanism, before Visual Studio 2008, Win32 applications were aligned on 4096 byte boundaries unless you added the /OPT:NOWIN98 switch to the linker. The linker for VS 2008 and later now uses 512 alignment by default.)
|
|
|
|
|
Hi Joe,
The /OPT:NOWIN98 should be sdded at which place of project settings? How?
|
|
|
|
|
In Visual Studio 2003/2005 it's in Properties|Linker|Optimization. Select "No (/OPT:NOWIN98) Only set this for Release mode.
In Visual Studio 2008, this will generate a warning, so it should be set to Default.
In Visual C++ 6.0, go to Settings|Link. In the Project Options Edit control, go to end and manually add "/OPT:NOWIN98"
|
|
|
|
|
Joe, thanks,
The min change is from 4096 to 512 bytes now.
cheers.
|
|
|
|
|
How are you looking at the size? If you're looking at the Windows Explorer, it only shows size in "cluster" increments.
Open a command window and use the "dir" command to see the actual files size at the byte level.
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
krmed wrote: Open a command window and use the "dir" command to see the actual files size at the byte level.
Better still, right click in Explorer and select Properties .
|
|
|
|
|
krmed wrote: If you're looking at the Windows Explorer, it only shows size in "cluster" increments.
It also shows the file's actual size, not just its size on disk.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Unless you have a different Windows Explorer than I do, it only shows one size - and it's not the actual size.
But perhaps you were responding to the idea of looking at the properties?
Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
|
|
|
|
|
krmed wrote: But perhaps you were responding to the idea of looking at the properties?
Correct.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
I've recently started using the XP styles look by using a manifest on an MFC application, and overall it looks fine.
The problem is a specific screen I have, which uses quite a few Comboboxes and Edit boxes. Everything works basically as before, only much much slower than it used to. When I change back and remove the manifest, everything changes back to regular speed.
Can anyone help me solve this speed issue? The hope is to be able to retain the XP-style look while not slowing down so significantly. Any help would be appreciated, thank you.
|
|
|
|
|
Using VC6 & MFC
I have dialog with an edit box for the user to enter an integer number. I have set the number property in the resource sheet (ES_NUMBER) to handle entering numbers. Now everything is fine in that I can enter numbers and catch the new member value in my OnChangeEdit......() function.
However !
If you have say "3" in the edit box and you want to change it to say "4", a legitimate way for the user to do this is to press backspace to delete the "3" character and type "4" to set the new value.
But if you do this I get a message box saying "Please enter a positive integer." on using the backspace key switfly followed by an exception and program crash. Not very elegant !!
I have tried to intercept this with break points in OnChangeEdit or DoDataExchange of the dialog but it never gets there before the message box pops up.
Appart from priseing out the backspace key from the keyboard is there way to get around this ? It looks to my like a glaring whole in the default way MFC works. Other more learned people than me must have hit this plenty of times ?
Neil
|
|
|
|
|
Have you added any filters or made any unusual changes? I have number edit-controls as well but I don't get message boxes nor exceptions.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
I have a spin control associated with it via the AUTO_BUDDY mechanisam. I have used SetRange in OnInitDialog() for the spin control.
|
|
|
|
|
Neil Urquhart wrote: I have used SetRange...
With what values?
I tried to reproduce this behavior but it works fine for me. I added one edit control and one spin control. I added the ES_NUMBER style to the edit control. I added the UDS_SETBUDDYINT and UDS_AUTOBUDDY styles to the spin control. I used 1,5 as the range. You must have something else in place that is interfering.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
 Having produced a reduced version of my dialog I have tracked to source of the exception.
It seems using UpdateData(FALSE) in the OnChangeEdit1() is the source of the problem. Without it I don't get the exception. Its probably not required anyhow. I don't understand why it only causes the problem when the string in the edit control is empty.
This is the code which causes the exception :
#include "stdafx.h"
#include "CEditTest.h"
#include "CEditTestDlg.h"
#define IDT_UPDATE 1000
#define UPDATE_INTERVAL 1000
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
class CAboutDlg : public CDialog
{
public:
CAboutDlg();
enum { IDD = IDD_ABOUTBOX };
protected:
virtual void DoDataExchange(CDataExchange* pDX);
protected:
DECLARE_MESSAGE_MAP()
};
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
}
void CAboutDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
}
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
END_MESSAGE_MAP()
CCEditTestDlg::CCEditTestDlg(CWnd* pParent )
: CDialog(CCEditTestDlg::IDD, pParent)
{
m_edit1 = 0;
m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
bDlgInitDone = FALSE ;
}
void CCEditTestDlg::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
DDX_Control(pDX, IDC_SPIN1, m_spin1);
DDX_Text(pDX, IDC_EDIT1, m_edit1);
}
BEGIN_MESSAGE_MAP(CCEditTestDlg, CDialog)
ON_WM_SYSCOMMAND()
ON_WM_PAINT()
ON_WM_QUERYDRAGICON()
ON_WM_TIMER()
ON_EN_CHANGE(IDC_EDIT1, OnChangeEdit1)
END_MESSAGE_MAP()
BOOL CCEditTestDlg::OnInitDialog()
{
CDialog::OnInitDialog();
ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
ASSERT(IDM_ABOUTBOX < 0xF000);
CMenu* pSysMenu = GetSystemMenu(FALSE);
if (pSysMenu != NULL)
{
CString strAboutMenu;
strAboutMenu.LoadString(IDS_ABOUTBOX);
if (!strAboutMenu.IsEmpty())
{
pSysMenu->AppendMenu(MF_SEPARATOR);
pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
}
}
SetIcon(m_hIcon, TRUE);
SetIcon(m_hIcon, FALSE);
m_spin1.SetRange(1,99) ;
SetTimer(IDT_UPDATE, UPDATE_INTERVAL, NULL) ;
bDlgInitDone = TRUE ;
return TRUE;
}
void CCEditTestDlg::OnSysCommand(UINT nID, LPARAM lParam)
{
if ((nID & 0xFFF0) == IDM_ABOUTBOX)
{
CAboutDlg dlgAbout;
dlgAbout.DoModal();
}
else
{
CDialog::OnSysCommand(nID, lParam);
}
}
void CCEditTestDlg::OnPaint()
{
if (IsIconic())
{
CPaintDC dc(this);
SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0);
int cxIcon = GetSystemMetrics(SM_CXICON);
int cyIcon = GetSystemMetrics(SM_CYICON);
CRect rect;
GetClientRect(&rect);
int x = (rect.Width() - cxIcon + 1) / 2;
int y = (rect.Height() - cyIcon + 1) / 2;
dc.DrawIcon(x, y, m_hIcon);
}
else
{
CDialog::OnPaint();
}
}
HCURSOR CCEditTestDlg::OnQueryDragIcon()
{
return (HCURSOR) m_hIcon;
}
void CCEditTestDlg::OnTimer(UINT nIDEvent)
{
switch (nIDEvent) {
case IDT_UPDATE :
KillTimer(nIDEvent) ;
UpdateData(TRUE) ;
UpdateData(FALSE) ;
SetTimer(IDT_UPDATE, UPDATE_INTERVAL, NULL) ;
break ;
default :
CDialog::OnTimer(nIDEvent);
}
}
void CCEditTestDlg::OnChangeEdit1()
{
if(bDlgInitDone) UpdateData(TRUE) ;
TRACE("value is %d\n", m_edit1) ;
}
|
|
|
|
|
Neil Urquhart wrote: It seems using UpdateData(FALSE) in the OnChangeEdit1() is the source of the problem.
UpdateData() is rarely, if ever, necessary. Remove it, use a CEdit control variable, and your troubles will cease.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|