|
|
In VC++ How to read the data directly from file into CSring object.
anil
|
|
|
|
|
use CStdioFile mfc class
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Dear friends,
we have Install mac os on PearPC. we have create 6GB hard disk image.
During Installation, we are getting error" unable to install bundle
software on this computer".I think this error is due to 6 GB hard disk
image. so pls suggest any proper solution to us, so we are able to solve
our problem. also suggest any forums related to this issue, so i will
post my query on this forums.
I know this is not related to Mac Os forum. But if you know soln of this
problem , give me a reply.
Regards
kedar
Girish
Software Developer
|
|
|
|
|
vcforums wrote: know this is not related to Mac Os forum. But if you know soln of this problem , give me a reply.
I believe, you will get better answer at MAC forums.. as user here are more Familiar wityh Windows Os only
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
cheers,
Alok Gupta
VC Forum Q&A :- I/ IV
|
|
|
|
|
Dear All
I want to write a dialog based application where user is prompted to choose some file using CFileDialog. I have to open the file selected by the user with default Shell editor associated
with that file from my application ( For e.g, if user selecets "Sample.bmp", i must be able to
run "mspaint.exe" application with "sample.bmp" opened for editing from my application ) and i must not allow user not to do any operation with my application till he closes the opened application.
Can somebody help me in implementing this functionality.
Thanks in advance
Regards
Krishna
|
|
|
|
|
Hi,
you can use ShellExecuteEx() and the use the handle to the created process returned by it to check its existence.
Bye,
Cool Ju 
Dream Ur Destiny
-- modified at 4:07 Friday 10th February, 2006
|
|
|
|
|
Try this :
CString csCommand = "C:\\WINDOWS\\system32\\mspaint.exe c:\somewhere\sample.bmp";
DoExecCommand( csCommand, TRUE );
BOOL CMyDialog::DoExecCommand( CString csCommand, BOOL bWait )
{
STARTUPINFO si;
::ZeroMemory(&si, sizeof si);
PROCESS_INFORMATION pi;
::ZeroMemory(&pi, sizeof pi);
char* pszCmd = csCommand.GetBuffer(0);
BOOL bResult = CreateProcess( NULL, // pointer to name of executable module
pszCmd, // pointer to command line string
NULL, // process security attributes
NULL, // thread security attributes
FALSE, // handle inheritance flag
NORMAL_PRIORITY_CLASS, // creation flags
NULL, // pointer to new environment block
NULL, // pointer to current directory name
&si, // pointer to STARTUPINFO
&pi // pointer to PROCESS_INFORMATION
);
if(bResult)
{
if(bWait)
{
DWORD dwResult = WaitForSingleObject( pi.hProcess, INFINITE );
}
CloseHandle( pi.hProcess );
}
return( bResult );
}
|
|
|
|
|
Hi all,
I'm wondering would you prefer to use typedef to define a new type name than using the #define? Since macro should be avoided as much as possible, would you say typedef is better?
Is there any difference?
Thanks
|
|
|
|
|
hi
if you use typedef , you can't use the typdef specifiers inside function definitions ,however if you use #define you need to be careful with arguments since they may produce unexpected results.
"Every morning I go through Forbes list of 40 richest
people in the world. If my name is not in there, I go to
work..!!!"
|
|
|
|
|
Link2006 wrote: typedef is better
Sure, typedef is a thousand times better. First, a type defined by a typedef is ... a type, whereas a #define does not have any type. Type checking at compilation type is not done with #defines, type casting is much safer when used with types. Avoid #defines as much as possible.
~RaGE();
|
|
|
|
|
Rage wrote: Type checking at compilation type is not done with #defines, type casting is much safer when used with types
Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
Rage wrote: Avoid #defines as much as possible
I can agree on this if you would use it solely as a typedef replacement.
But #defines are very usefull to make codeing easier like constants and macros
codito ergo sum
|
|
|
|
|
BadKarma wrote: Wrong,
since the #define is replaced before the compilation the compiler can check for type casting issues.
#define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
BadKarma wrote: #defines are very usefull to make codeing easier like constants and macros
I won't go into a flame war, but const is definitely better than a #define.
I agree though than SIMPLE macros can be useful.
~RaGE();
|
|
|
|
|
Hi,
don't take this wrong, but the question was which is preferred,
using #define or typedef to create a new type. You said its preferred
to use typedef (which I agree ) because when using #define the compiler
wouldn't be able to check the types.
I just stated the latter, as false.
Rage wrote: #define a 3
I agree that the 3 doesn't resemble a single type, but that wasn't what i meant.
Rage wrote: ..., but const is definitely better than a #define.
I could agree to this if one is writing an application for Computer based systems.
But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
And when it comes to MFC there is no such thing as a SIMPLE macros 
codito ergo sum
|
|
|
|
|
BadKarma wrote: to create a new type
Actually I even never considered using #define for creating types.
BadKarma wrote: I just stated the latter, as false.
Well, Ok.
BadKarma wrote: But when writing for embeded systems, where 2MB of memory is already considered to be a luxery,
every byte that you can save by using #defined constants is worthwhile.
I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
If the const is loaded in RAM, which it should not, then the compiler does not optimize it correctly.
If the const is used in ROM, then it makes no difference with the #define, since the #define is replaced in-place in the code before compilation, but the value is also in the ROM.
~RaGE();
|
|
|
|
|
Rage wrote: I am also writing software for embedded systems (and we only have 512Ko), but I do not see where you save memory when using #defines.
You save memory because if you use const, the value is placed in ROM as a variable, and the compiler creates code to load it from memory like a variable every time it is needed. It (usually) takes more time and memory than if the compiler just loads an constant value.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Rage wrote: #define a 3
What is a ? an unsigned int ? a signed int ? a char ? ...
My guess to the answer - the type of "a" is not determined in the #define statement - it depends on where "a" is used in the program. As far as I know, "a" is replaced by "3" by the pre-compiler before compilation, so it may be treated as a char in one part of the program and as an int in another, etc.
So if you had the following code:
#define defValue3 3
char cOneChar;
int iIntVar;
cOneChar = defValue3 + 32;
iIntVar = defValue3 + 32;
|
|
|
|
|
Never, ever use #define to define new types. It's just asking for trouble.
One reason the others haven't mentioned yet is multiple variable definitions on one line. Say you do this:
#define INTPTR int*
INPTR p1, p2; You may think that p1 and p2 have the same type... They do not. p1 is an int* and p2 is an int. The preprocessor expands the macro definition to produce
int* p1, p2; Remember that the * modifies the variable, not the type, so the * only makes p1 a pointer.
Typedefs don't have this problem
typedef int* INTPTR;
INTPTR p1, p2; behaves exactly as expected.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Ryan Binns wrote:
int* p1, p2;
You would not advertise this style, no? 
Were not doing C here - this is C++! 
When you really need the variable - that is when you are ready to give it a value - declare it like so:
int* p1 = WhateverGetsMeAnIntPtr();
or better still
int* p2( WhateverGetsMeAnIntPtr());
Stop definig variable you might end up not using.
Start definig variables when you need them.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Right ...
Until your compiler says "initialization of variable declared when needed skipped by goto" ... then you go back to declaring them all at the top of your function 
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: ...goto...
Hmm - this sounds like Linux driver code.
Or is someone else still using goto on a regular basis?
Anyway, if you jump over one part of your code and are missing variables later, your code is deeply flawed anyway.
Some variables do need to exist throughout the whole function - most are not.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
Well, I don't like to if( ...) statements nested 10 levels deep, and I am not fond of returns sprinkled throughout a function either. So ... goto FuncExit; in case of error. FuncExit is at bottom of funtion.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
Blake Miller wrote: not fond of returns sprinkled throughout
For me, this is only a venial sin against the spirit of OO.
And a goto does make nothing clearer.
But when you only jump down to the return, you should miss no variables?
Sorry if I miss something obvious.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation."
-- Caius Petronius, Roman Consul, 66 A.D.
|
|
|
|
|
We use goto a lot in functions that call other functions returning error codes.
suppose some pseudo-code like this...
if string pointer is null or string is empty
set error code
goto funcexit
if file can not be opened
set error code
goto funcexit
if file read error happens
set error code
goto funcexit
if memory allocation for structure fails
set error code
goto funcexit
FuncExit
if file opened
close file
return
-----------------
If you declare file handles, etc. as you need them, then the compiler will complain that the 'initialization' of the type was skipped by the goto.
In this case, the if statments would have only nested 5 levels deep ... ugh.
But in soeem of our more complex processing, there might be 15-20 function calls which might fail before the actual 'work' begins.
I WISH we were all OO - parts of this code base are untouched since the days of our company founders - back in 1989!
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
<sarcasm mode=true>
OMG :doh:
using a goto in c++, X|
why dont you use the functions <code>longjmp</code> and <code>setjmp</code> to write entirely incomprehensible code :laugh:
<sarcasm mode=false>
I known what you mean, because even in a switch you can have this problem.
but then again you could use { } to define the scope of that variable.
codito ergo sum
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
