|
But Does your code Compile, or not?
Regards...
"The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a software patch and a user with an idea."
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
like this:
#include<windows.h>
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
MessageBox(NULL, TEXT("hello"), TEXT("caption"), 0);
return 0;
}
it can run in VC,buy can't in BCB 5
why?
hi
|
|
|
|
|
Some time ago I remember seeing an example of how to do a clrscr() in VC, without using system("cls") way. But now I can't find the example/program anywhere... Are there someone out there who can help me find this example again?
|
|
|
|
|
the function is _clearscreen(_GCLEARSCREEN);
Is declared in graph.h
Regards
There are two ways to write error-free programs; only the third one works.
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
#define PERR(bSuccess, api){if(!(bSuccess)) printf("%s:Error %d from %s \
on line %d\n", __FILE__, GetLastError(), api, __LINE__);}
void cls( HANDLE hConsole )
{
COORD coordScreen = { 0, 0 }; /* here's where we'll home the
cursor */
BOOL bSuccess;
DWORD cCharsWritten;
CONSOLE_SCREEN_BUFFER_INFO csbi; /* to get buffer info */
DWORD dwConSize; /* number of character cells in
the current buffer */
/* get the number of character cells in the current buffer */
bSuccess = GetConsoleScreenBufferInfo( hConsole, &csbi );
PERR( bSuccess, "GetConsoleScreenBufferInfo" );
dwConSize = csbi.dwSize.X * csbi.dwSize.Y;
/* fill the entire screen with blanks */
bSuccess = FillConsoleOutputCharacter( hConsole, (TCHAR) ' ',
dwConSize, coordScreen, &cCharsWritten );
PERR( bSuccess, "FillConsoleOutputCharacter" );
/* get the current text attribute */
bSuccess = GetConsoleScreenBufferInfo( hConsole, &csbi );
PERR( bSuccess, "ConsoleScreenBufferInfo" );
/* now set the buffer's attributes accordingly */
bSuccess = FillConsoleOutputAttribute( hConsole, csbi.wAttributes,
dwConSize, coordScreen, &cCharsWritten );
PERR( bSuccess, "FillConsoleOutputAttribute" );
/* put the cursor at (0, 0) */
bSuccess = SetConsoleCursorPosition( hConsole, coordScreen );
PERR( bSuccess, "SetConsoleCursorPosition" );
return;
}
IMO never seen any clrscr() type function in VC.
The above will help you to clear the console.
Atul
Sonork ID : 100.13714 netdiva
|
|
|
|
|
Hi,
I am developing a VC++ application in which I have a dialog (Class corresponding to it say CDialog1).
I have a pointer of this dialog class (CDialog1 * myDlg) as a member in the Application Class.
I am bringing up this dialog when one of the menu item of the application is clicked.
In this dialog's OnClick( ) event of a button I am destroying its pointer (that is destroying myDlg variable). Further in the OnClick() function I have a Messagebox to be populated with some value. We see the message box is displayed.
Can anyone explain me how this happens, even though I am destroying the object of the class the rest of the function code is executed how. I have a feeling that its something to do with the event handling?
Please reply back to my mail id.
TIA,
Rgds,
Vikas.
|
|
|
|
|
Let me be sure I'm understanding you. Your have a dialog object dynamically created, pointed to by (CDialog *myDlg) and inside a member function of that dialog, you're (delete myDlg)'ing it?
If I'm right, then that leads to two points:
1. Why?
2. IIRC an object trying to delete itself is "undefined" behaviour.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
Here goes:-
I have an application where one dialog is active at a time.
I want to destroy the active dialog on the click of a button present on that dialog and bring up another dialog.
The surprising thing here is that in the function OnClick( ) the destructor of the dialog is called first as I am deleting the dialog pointer and then the remaining part of the code is executed.
What is nagging me is how this is possible that even after deleting the dialog a member function of that dialog is still executing ??
I am enclosing the code to make my point clearer:
void CDialog1::OnButton1()
{
theApp.myDlg->DestroyWindow();
delete(theApp.myDlg); //Destructor is called at this point
theApp.myDlg = NULL;
AfxMessageBox("This function is continued after the destructor");
}
Here the message box should not be displayed, but surprise surprise !!
The message box is displayed and the application works fine.
Any answers ??
|
|
|
|
|
Don't try and delete the dialog from within the dialogs member function.
As a rule of thumb, and yes, there ARE many exceptions, but you should delete an object in the same block as you new'ed it in the first place. unless you specifically want the object to remain in existence once that code block is out of scope.
What you should do is this...
Your "theApp" object is the object that created the dialog, and called DoModal() on it. Since the dialog is modal, that thread blocks until the dialog closes.
Try something like this:
CMyWinApp::Whatever()
{
CDialog1 *myDlg;
CDialog2 *myDlg2;
BOOL bShowDlg1=TRUE;
do {
if (bShowDlg1) {
myDlg = new CDialog1;
myDlg.DoModal();
delete myDlg;
bShowDlg1=FALSE;
} else {
myDlg2 = new CDialog2;
myDlg2.DoModal();
delete myDlg2;
bShowDlg1=TRUE;
}
} while (TRUE);
}
Then, in your dialogs:
CDialog1::OnClick()
{
PostMessage(WM_CLOSE,0,0);
}
I expect you'll need to modify that to meet your exact needs. But you should take the pertinant points, that being to close the dialog with PostMessage() and have the parent object handle allocation and deallocation of the dialog.
Jon
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
When you destroy an object you delete the struct which keeps the member variables and the VTABLE. You don't "delete" the implementation of the member functions. A method of an object is a function with the "this" calling convention ( the "this" pointer is passed to the function thru the ECX register). So the behavior is as expected.
|
|
|
|
|
That explains things nicely.
Personally, i can't think of any real world situation where an object should delete itself. Can anyone point one out?
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
Think technique is used ( for example )when you implement COM objects and the last reference to the object is released :
ULONG MyObject::Release()
{
if( -- m_dwCount == 0 )
{
delete this;
}
return m_dwCount;
}
|
|
|
|
|
In what you have explained above, are we violating any thing or is it a perfectly acceptable implementation?
|
|
|
|
|
Technically it's ok, it's only a matter of coding style.
|
|
|
|
|
can anyone tell me how do i pass and return an array of Objects?
thanks
|
|
|
|
|
use the STL vector class.
Tim Smith
Descartes Systems Sciences, Inc.
|
|
|
|
|
Or, if you don't want to use STL, you could use CObArray from MFC.
or, you could do it like this:
CMyObject arrayMyObjects[10];
for (int i=0; i<10; i++)
{
arrayMyObjects[i].Initialise(or,whatever,you,want,to,do);
}
thats just like using an array of char or int.
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
ok here is my problem:
Stock myStocks[15];
Stock* getMyStocks()
{
return myStocks;
}
binarySearch(Stock* stockArray, int f, int l, char* key)
(
//code blabla
return mid;
)
//when i try to use this last method binarySearch
tempStocks->binarySearch(tempStocks->myStocks, 0, 14, tempSomething)
//here is the error i get:
//cannot convert parameter 1 from 'class Stock* (void)' to 'class Stock*'
//there is no context in which this conversion is possible
DOES ANY ONE SEE where the problem is?
|
|
|
|
|
Explicitly cast mystocks as (Stock *)
ie.
tempStocks->binarySearch((Stock *) tempStocks->myStocks, 0, 14, tempSomething);
Also, it's Very Good Practise to name all your classes with a C.. prefix. This can save a lot of confusion.
JOn
Sorry to dissapoint you all with my lack of a witty or poignant signature.
|
|
|
|
|
USe the CArray class from MFC, you have a couple of options, you can use CArray or CList, one use index on the other one use Positions...
Regards!!!!
A printer consists of three main parts: the case, the jammed paper tray and the blinking red light
Carlos Antollini.
Sonork ID 100.10529 cantollini
|
|
|
|
|
It should be added that
a/ CArray is an array class, and CList is a linked list
b/ unlike STL, if you use MFC container classes you'll need to write al your own algorithms for sorting, partitioning, shuffling, etc.
c/ This guy is really struggling with an assignment and he's not allowed to use std::string, let alone crappy MFC classes.
Christian
I have come to clean zee pooollll. - Michael Martin Dec 30, 2001
Picture the daffodil. And while you do that, I'll be over here going through your stuff.
|
|
|
|
|
Hi,
Is there anyway to get back the proper cpp file which is been corrupted?.I have the .obj file also,is it possible to get the .cpp file from .obj file.
Could anyone pl help me...
|
|
|
|
|
No, it is not. I should think not, anyway.
If it is a debug version then you might be able to extract some of the code, but mostly it will be garbled.
Since it's not a proper exe, you cant even disassemble it which would in any way have given you only an asm version.
Nish
Sonork ID 100.9786 voidmain
www.busterboy.org
If you don't find me on CP, I'll be at Bob's HungOut
|
|
|
|
|
It was in a debug version.i could extract some code.not completely.I have the proper exe of my application.how can i go about to get atleast the asm version.
|
|
|
|
|
If you have the .exe of your app then you can use a disassembler to get the asm version (however IMO I do not know how much of use is this). You can try using one of the best disassembler's, URSoft's W32Dasm v8.93.
If your exe is debug release then you will get as is asm i.e. without any optimizations like entire code knockout's.
Atul
Sonork ID : 100.13714 netdiva
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
