|
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
|
|
|
|
|
SHORT ANSWER:
Use the standard template vector<> (#include <vector>).
If you know the (aproximate) number of elements needed for storage, before coping, then call the member function reserve(), in order to reduce the number of reallocations required when adding new elements to the array.
LONG ANSWER:
The best solution depends on how it is going to be used (implimentation dependent). If you need a dynamic array (increases/decreases size as needed) then use the vector<> template (which is a one dimensional dynamic array). The maximum size of an array of elements, depends on the size of the elements and amount of memory available.
If you use a vector, you can call the max_size() member to determine what is, theoretically, the maximum number of elements that can be stored in a vector. I say theorectically because it, again, depends on the size of the element being stored, the amount of available memory and the amount of contiguous memory that can be allocated (on a given system).
THAT'S ENOUGH:
In C++ just use vector<>, unless you have a good reason not to.
NOTES:
1) Never use type* pArray = new type[size] when type Array[size] will solve the problem.
2) Prefer:
vector<type> myarray;
myarray.reserve(size);
TO
type* pArray = new type[size];
Good Luck!
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
hi,
have an SDI application where the view class has been derived from the CFormView class. i added a list control to the dialog. but when i tried to add some sample text to it i got and exception. in some earlier posts someone had suggested to define the virtual function DefWindowProc. and in the handler for the WM_INITDIALOG message call UpdateData(FALSE). i tried that but i am still getting the exception. can anyone help
thanks
aditya
|
|
|
|
|
I assume you have a member variable that has been subclassed to the control in question. This might have been done for you. Use the debugger to make sure that m_hWnd is not NULL prior to adding the sample text to the list box. If it is NULL, make sure that the resource ids haven't changed and that the control id is correct for the control. This often causes problems.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
I'm looking for a "multi-slider" control that contains n (>= 1) knobs to allow for the definition of contiguous ranges. An example of one with 6 knobs would look like this:
(min)...|.......|..|....|.......|...|..(max)
1 2 3 4 5 6
A pointer to existing code would be much appreciated. Thanks!
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
|
it took awhile to figure out what the correct image link was, but here it is [^]
seems there are tons of broken links on CodeGuru... 
Steve
|
|
|
|
|
Steve Mayfield wrote:
seems there are tons of broken links on CodeGuru...
No surprise. 
/ravi
My new year's resolution: 2048 x 1536
Home | Music | Articles | Freeware | Trips
ravib(at)ravib(dot)com
|
|
|
|
|
|
Strange occurance ?
In one dialog, i call this
myDlg = new CmyDlg;
myDlg ->Create(IDD_DIALOG, GetDesktopWindow());
myDlg ->ShowWindow(1);
Now I have a thread running, if it receives a message, it'll sometimes popup a MessageBox window, but the MessageBox will be under everything. I want the message to popup ontop of everything.
If I call from the thread, with MessageBox(GetForegroundWindow(),...); It'll popup the message box, but then the application will lock.
Not sure what's causing it, and if I do MessageBox(NULL,...) it'll run fine except the MessageBox is under everything ..
?
|
|
|
|
|
I got it, just tagging MB_SYSTEMMODAL to the function.
Btw, why does it do that ?
|
|
|
|
|
Well not realy: MB_SYSTEMMODAL suspends all applications (equivalent to locking up all applications), until the dialog is close.
If you are using MFC, try: AfxMessageBox(...).
I have only used it few times my self, but it should set the hWnd parameter to your main application window or the currently active window in your application (or possibly NULL). If it works then single step into it and find out why.
MessageBox(NULL,...): Should popup the modal messagebox in front of all the windows, it has no parent (actualy that's not true, but the docs say it is) (It has always worked for me).
Search previously asked questions: Some one was having this same problem last week (my be some one knew what the problem was).
The (probable) reason no one has attempted to answer this question is that it does not happen. The only time I've seen this, is when a messagebox popups and the user does not close it, but clicks on the window that the messagebox is in front of (sending the messagbox to the background).
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Yea it is quite strange, but got it working. Just plugged in system modal.
|
|
|
|
|
I have an application that was originally developed with Windows 98 ( yes, just recently bought new laptop with XP Pro). I have also occationally built the app. on my work PC which runs Windows 2000. No difference there. But when I now try to build with XP all dialogs and CFormViews come out wrong with static texts in shifted positions relative to edit boxes, etc. The environment is VC6.0 service pack 3.
Regards, Haakon S.
A sure cure for seasickness is to sit under a tree.
Spike Milligan
|
|
|
|
|
No need to be . Win98 (?) and Win2000 (great stystem) have a lot in common, but that is where you should have seen problems (if any).
Each system may use a different default character set, which will affect any windows layout that resembles a dialog (that applies to internationalization as well). That means the static text bounding rectangle should be larger than the default size, which is based on the default font size at design time. (You might need to throw in some calculations as well.)
I recommend making a copy of your application and modifing it on XP so that it looks right. Then compare it to the original program (visualy), to see what the difference is. (That may be enough for you to figure out the problem.)
INTP
"The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes."
Andrew W. Troelsen
|
|
|
|
|
Thanks for the reply!
I found the cause of the problem. It is as simple as DPI (pixels, or dots, per inch). In my program I have used SepMapMode(MM_TEXT). In the dialogs and CFormViews there will be a mix of this mode and DLU (dialog logical units). The former is dependent on the device, the latter is calculated from the font size, which is device independent. Now, that is something to be about. I should of course have used SetMapMode(HI_METRIC), or some such thing.
My new PC has default DPI=120. By changing this to 96 (designated Normal by Windows) my program works fine.
Regards, Haakon S.
A sure cure for seasickness is to sit under a tree.
Spike Milligan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
