|
#pragma warning must be outside the body of a function...
do you verify this ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
even better, it is declared in the stdafx.h above all the includes...
what about my other problem and question?
any1?
thanks
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
hi
i want to know can we read dbf file with odbc if yes which driver should be used to mak the dsn.
ddd
|
|
|
|
|
Yes, DBF files can be read using ODBC. Look in your machine's list of installed drivers to see which one(s) can handle DBF files. Last time I checked, that was a dBase file format.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
thank u it works.
honesty is the best policy.
|
|
|
|
|
I am building a window in code (not via RC or dialog templates) and attaching EDIT controls to it. Upon completion, there may be 10 windows with 25 EDIT controls each.
Within each window (one displayed at a given time) I'd like to TAB between the EDIT controls. Unfortunately, the only examples I can find on the net (http://blogs.msdn.com/oldnewthing/archive/2003/10/21/55384.aspx)
want me to change my message loop to something like this:
if (IsDialogMessage(hwnd, &msg)) {
/* Already handled by dialog manager */
} else {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
My message loop is in a completely different C++ file/class. For this to work as described, I'd need to pass the application (or make it global) to every single EDIT control - or at least, find away to keep updating the "hwnd" used in the IsDialogMessage method above every time focus changed since that method works on a specific EDIT control at a time ...
Is that really necessary? I've built the EDIT controls with WS_TABSTOP style, and naturally, they are eating the TAB key. I can manually catch and GetNextDlgTabItem myself, but I wasn't sure if that was normal.
Is there a cleaner way I've overlooked?
Many thanks,
-Luther
|
|
|
|
|
Once you have built them, you could
SetWindowPos(CWnd* pWndInsertAfter,
int x, int y, int cx, int cy, UINT nFlags );
where
pWndInsertAfter identifies the CWnd object that will
precede this CWnd object in the Z-order.
|
|
|
|
|
I'm not sure how that helps me?
If I am in a TEXT EDIT box - and I press the "TAB" key, the MessageBell goes off and the "TAB" key is sent to the TEXT EDIT box.
If I manually catch the "TAB" key in a WM_CHAR message and manually call GetNextDlgTabItem and then SetFocus(nextItem) ... I get the behavior I want.
The ordering is fine. When I manually tab, I tab to the correct TEXT EDIT box. The problem is not the ordering or where I am going. The problem is catching the "TAB" key before it is sent to the EDIT TEXT box. That is what IsDialogMessage handles for me.
I'm just looking for some common idiom to handle this - since IsDialogMessage needs the HWND to check and IsDialogMessage must exist with the main message loop - 100,000 miles (so to speak) away from the rest of my code.
Does that help clarify anything? Thanks,
-Luther
|
|
|
|
|
Is it a modeless dialog? I'm having the same problem.
In modal dialogs, WS_TABSTOP does the job you want: send focus to the next control in the tab order when tab is hit. Modeless, nope...I get the same behavior. Help anybody?
|
|
|
|
|
Hi,
I am upgrading VC compiler on a windows machine from version 6.0 to 7.1
After upgrading when I tried to compile my application and got this error
\\Vc7\atlmfc\include\atlalloc.h(218) : error C2629: unexpected 'class ATL::CTempBuffer ('
I was able to compile code on 6.0 version
I am getting this error whenever "atlalloc.h" is included directly or indirectly in my cpp file.
Please tell me how to fix this
Regards... Ankur
|
|
|
|
|
some code that was compiling good under VC6 can fail under VC7 because not Standard C++ compliant anymore...
what is the failling code please ?
TOXCCT >>> GEII power
[toxcct][VisualCalc]
|
|
|
|
|
I'm trying to rewrite an assembly program in C++. Instead of reinventing the wheel, I am cutting and pasting a lot of asm into __asm blocks. However, whenever I try to call int 0x21, I get an unhandled exception. Why is this and how do I get around it?
|
|
|
|
|
In this case you need to reinvent (most of) the wheel. The call int 0x21 (MS-DOS call) is probably allocating memory from the Upper Memory Area (UMA), which implies 16-bit code (old code). I am just surprised that that is the only problem you are asking about.
If you need to rewrite this old code, then you need to understand it:
1) You need to know what programing language the assembly code was ment to be accessed from (assuming it is not entirely in assembly).
2) Which version of the compiler was used (if possible).
3) Which processor it was written for (probably intel386).
4) What each of the assembly commands mean (+ what each function call does).
5) etc...
6) Break out or find the old books, on the calling language and the assembly language used.
The fact that you are trying this implies that you have a good idea of what you are attempting to do. If the assembly code (that calls int 0x21) represents a function call and you just copied it into and __asm block, in a C/C++ function, then post the funtion code.
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
The assembly program was a stand alone application; it was not called from anywhere. I wanted to add some functionality to it, but it's been so long since I've programmed in asm that I've forgotten most of it. The compiler that was originally used to compile it was a86. It was written for the 286 intel processor. (16bit only) I'm familiar with most of the code and what it's supposed to do since I had left some comments here and there, but this is the first time I've ever tried to put asm and c++ in the same program.
Here is a block of code that's causing me problems:
;//;open file using handle (r/w)
lea dx, name
mov ax, 3D02h
int 0021h
jc end
xchg ax, bx
basically what it does is load the address of filename in memory into dx. name is a NULL terminated char array defined in the main() function. Then move 3D02 into ax. This will cause int21 to call function 3d which is the open filename command. The 02 byte in AL specifies to open the file in r/w mode. Then int21 is called to open the file. Afterwards the Carry flag is checked to see if the open was a success or failure. This should catch any errors with the open and prevent the program from crashing. (and yes, the label "end" is inside the same __asm block as the above code). Finally ax and bx are exchanged to put the file handle in bx. The next function called in asm code will require the handle be in bx, so might as well put it there now.
I debuged the above code and it crashes when it gets to the call to int21. I'm not sure what to do from here.
Also, I'm running Windows XP with a NTFS filesystem. When I run the asm code after it was compiled with a86, it runs fine. 
thanks!
|
|
|
|
|
I was thinking about a function call such as this (so I could call it):
return_type OpenFile(char* name)
{
__asm {
lea dx, name
mov ax, 3D02h
int 0021h
jc end
xchg ax, bx
...
}
...
}
Anyway, it does not matter.
I would go ahead and reinvent the wheel; actualy you are not reinventing the wheel, you are just bring it up to date. Things like accessing file I/0 should be handle at the current language level (things change). The only reason for keeping any of the code at assembly level is for speed.
Any of the assembly code you wish to keep and wrap in a function call should be wrapped in C function calls, so you do not have to deal with the difficulties (name mangaling) of C++.
Unless you are writting code at the driver level (ring 0), you normaly do not need to write assembly code. Modern day compilers are very good at otimising your code. Plus the fact that writting your code in C/C++ is much easier to understand (and modify).
Understand this: Under Win2000 and above the system will get upset if you try to access memory (read/write) without the proper security clearance, this is intended to defeat crackers/hackers.
__asm can be very useful, in time criticle applications. For good examples of its usage, see the source code for memset() and memcpy().
I know that I just told you to reinvent the wheel, but I realy beleive that is the best way to accomplish your goal (less headacks and, yes, less time in the long run).
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Interrupts are GENERALLY NOT ALLOWED in Windows!
There is only one exception: Interrupt 2Eh, which is used for communication between user mode and kernel mode.
Every other interrupt should cause an exception because it can only be called from Ring-0!
Don't try it, just do it! 
|
|
|
|
|
Are you really sure you couldn't just recreate this assembly language program's functionality in a straight C++ application? Almost anything you try to do via int 0x21 is an MS-DOS function call, which may or may not be emulated in the Windows environment (depending upon how you're running your application). The unhandled exceptions you are seeing are probably related to access denials.
Software Zen: delete this;
|
|
|
|
|
I'm sure I can recreate the program in strait C++. It just would be easier to reuse my old code if it were possible. If you truely can't use any interupts except 2E in __asm blocks under windows, then I don't see where __asm blocks would be useful for anything. In all the asm programs I've written, the code has consisted of mostly shuffling registers and interupt calls. Without using interupts, how can assembly language be useful for anything?
|
|
|
|
|
CorvetteZ0606 wrote:
Without using interupts, how can assembly language be useful for anything?
Unless you are using DOS-specific interrupts, or those that deal directly with hardware, you can do numerous things. But most assembly code has been "wrapped" by a much friendlier function. Since device drivers operate at ring 0 instead of ring 3, they are loaded with assembly code.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Assembly language still has its uses, even in modern Windows applications. The most common used are to either hand-optimize code that is performance-critical, or to use specific instructions out of the CPU instruction set.
Consider this, however. In over ten years of Windows application development, I've never had code that was so performance-intensive that I felt the need to write assembly language to speed it up.
Software Zen: delete this;
|
|
|
|
|
Summary:
m_hWnd is NULL in a CDialog derived class and this leads to an assertion failure.
Details:
I am writing an SDI application. I've subclassed a CDialog class that will popup and gather info from the user. In response to the user clicking some button the Document class handles the message and creates a new CDialog object and calls DoModal(). The basic idea is something like this:
<br />
void CMyDoc::OnButtonClick()<br />
{<br />
CMyDialog md;<br />
md.DoModal();<br />
}
Now, the CMyDialog class has a CTabCtrl named "m_tabSettings" with two tabs. I need to initialize these tabs and have tried to do so with code similar to this:
<br />
m_tabSettings.InsertItem(0,"Tab One");<br />
m_tabSettings.InsertItem(1,"Tab Two");<br />
This causes an assertion failure in AFXCMN.INL on the following line:
<br />
_AFXCMN_INLINE BOOL CTabCtrl::InsertItem(int nItem, LPCTSTR lpszItem)<br />
{ ASSERT(::IsWindow(m_hWnd)); return CTabCtrl::InsertItem(TCIF_TEXT, nItem, lpszItem, 0, 0); }<br />
The key part from above is: ASSERT(::IsWindow(m_hWnd));
I stepped through this code in the debugger and sure enough m_hWnd is 0x00 when I try to insert tabs into my CTabCtrl. I'v tried the following:
1. moving this 'insert item' code to the CMyDialog constructor (actually this is where I had it to begin with)
2. moving the 'insert item' code to a separate function which I call between the dialog declaration and DoModal()
3. changing the CMyDialog variable to a pointer and creating a 'new CMyDialog' on the heap
4. calling CMyDialog::Create() before the call to DoModal() ... and I played with creating a CMyDialog object from the CMyView class as well.
5. getting rid of the tab control initialization code altogether and inserting a CListCtrl in report form as a variable instead. I then tried to call CListCtrl::InsertColumn(0,"col one") ... etc.
All of these cause the same or similar assertion errors. I know, most of the stuff I've tried is some type of 'magic chicken coding' but I have no idea why code that I've pretty much copied from stuff I saw on the MSDN is breaking like this (i.e. I'm out of ideas) .
Is there some order of method calls that I'm missing or some flag for the CMyDialog?
If anyone has had a similar problem please let me know if and how they've fixed it.
|
|
|
|
|
You need to move the initialization to CMyDialog::OnInitDialog(), after calling CDialog::OnInitDialog(). Until that, the dialog controls aren't yet created.
You need to distinguish between the CWnd-derived C++ object that wraps the Windows control (e.g.: m_tabSettings) from the Windows control itself (e.g.: m_tabSettings.m_hWnd);
The dialog constructor constructs the control wrappers, DoModal first creates the Windows controls and then calls [1] OnInitDialog. CDialog::OnInitDialog associates each control wrapper with its corresponding window control.
[1] Actually, during the dialog creation, Windows sends a WM_INITDIALOG message, which is handled in the dialog by OnInitDialog.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
For those interested, I will now answer, at least in part, my own question.:
Solution:
Override CMyDialog::OnInitDialog() and initialize the CTabCtrl there.
As far as I've traced it, CMyDialog::DoModal() calls CDialog::DoModal() (i.e. the base class fn.). This I knew. What I didn't know is that CDialog::DoModal() calls my OnInitDialog() (or some funtion up(down,whatever) on the call stack before DoModal returns does). I just assumed that CMyDialog's constructor was calling OnInitDialog() . So, CDialog::DoModal() apparently initializes some stuff behind the scenes before it calls OnInitDialog() which allows me to init my controls safely.
It is late and I am too tired to dig further.
If anyone out there understands the sequence of behind the scenes initializations or whatnot that happens between the call to CDialog::DoModal() and the call to OnInitDialog() please explain.
|
|
|
|
|
Bah! Thats what I get for reading my post too many times before I click 'submit'. Thank you for your reply Jose!!
|
|
|
|
|
Hi There,
What's the best solution to use and implement an Array with maxixmum size of elements?
Thanks
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
