|
I have Window xp. VC++ 7.0.
Joe,
|
|
|
|
|
Tye to use the following code to set printer default:
PRINTDLG m_pd;
if (AfxGetApp()->GetPrinterDeviceDefaults(&m_pd))
{
LPDEVMODE pDevMode = (LPDEVMODE)::GlobalLock(m_pd.hDevMode);
pDevMode->dmOrientation=DMORIENT_LANDSCAPE;
::GlobalUnlock(hDevMode);
}
Lisoft
|
|
|
|
|
I tried this code, but it still prints portrait. I then added: dc.ResetDC(pDevMode);
just after: pDevMode->dmOrientation=DMORIENT_LANDSCAPE;
and it still not printing landscape.
Are there some library files that I have to include?
Never got any warning during compilation.
Joe,
|
|
|
|
|
When I compile any of mine projects with MS Visual C++ 6.0 there is alot of trash inside .exe file. Its looking like debug information although I'm building a release version (there are lots paths and filenames inside executable clearly viewable). How to remove it all, to reduce .exe size ? Why is it there ?
|
|
|
|
|
Exactly how are you viewing the .exe? with a hex viewer? I know that you can still usually find strings in most .exe's using the Win32 disassembler, (I think that's how some people find a message like "you have entered an invalid code" and use a hex viewer to change the 'jmp' statement to a 'nop'... or so I hear  ).
If I write code in my sleep, does that make me brilliant, or just a lazy programmer?
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
|
Yup I view it with hexviewer, but i bet it is visible with notepad too 
Yea you can crack programs by hexviewers, but disassemblers / hexview+dissaembler (like HIEW or DN) are better, trust me.
But anyhow, question is how to compile without the trash ? Now anyone can see my developement directories, and it grows my .exe too much. Is there some compiler switch or something ?
|
|
|
|
|
Yes, you need to disable the inclusion of the information for the PDB files.
Go to the Project menu and select settings.
A tabbed dialog called 'Project Settings' appears.
Make sure, on the left, the 'settings for' is set to something like "Win32 Release".
Go to tab marked 'Link'.
In 'Category' drop list box select 'Debug'.
Under 'Debug Info' group, make sure the 'Debug Info' check box is NOT checked.
Go to the 'C/C++' tab.
In 'Category' drop list box select 'Preprocessor'.
In the edit field 'Preprocessor definitions' make sure you see NDEBUG. If it is missing, then add it to end of list of other options. If you see DEBUG or _DEBUG in the list of items, then remove it.
That should help.
|
|
|
|
|
Thank you, but actually it didnt, because all those things were like that from the start, those are default Release settings.
|
|
|
|
|
I forgot to mention one more that might be different.
On the Project Settings : C/C++ with the drop down list box set to "General"
There is a 'debug info' drop down list box and that should be set to 'None'.
Since you said that it seems all the file paths are in your EXE, maybe this is set to 'Program Database' for your project.
I can't really think of another reason all the source paths are in your EXE unless someone has put something like
static char s_FilePath[] = __FILE__;
in all of your source files, which would automatically cause them all to be included.
|
|
|
|
|
Yup 'debug info' was set to 'none'
Of course im not using "static char s_FilePath[] = __FILE__;" that would be pretty dumb  why would I need absolute path to my project in the proggy generally absolute paths are bad thing.
Uh oh then ...
|
|
|
|
|
Take most C++ files generated by MFC AppWizards and you will find code similar to this at top of every source file...
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
So.... Why would you want to do that?
These are the only reasons I could locate...
#define TRACE ::AfxTrace
#define THIS_FILE __FILE__
#define ASSERT(f) \
do \
{ \
if (!(f) && AfxAssertFailedLine(THIS_FILE, __LINE__)) \
AfxDebugBreak(); \
} while (0) \
#define VERIFY(f) ASSERT(f)
#define ASSERT_VALID(pOb) (::AfxAssertValidObject(pOb, THIS_FILE, __LINE__))
#define DEBUG_ONLY(f) (f)
// Memory tracking allocation
void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine);
#define DEBUG_NEW new(THIS_FILE, __LINE__)
#if _MSC_VER >= 1200
void AFX_CDECL operator delete(void* p, LPCSTR lpszFileName, int nLine);
#endif
#ifdef _DEBUG
#define DAO_CHECK(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__)
#define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, err)
#define DAO_CHECK_MEM(f) AfxDaoCheck(f, #f, THIS_FILE, __LINE__, \
NO_AFX_DAO_ERROR, TRUE)
#define DAO_TRACE(f) AfxDaoTrace(f, #f, THIS_FILE, __LINE__)
#else
#define DAO_CHECK(f) AfxDaoCheck(f, NULL, NULL, 0)
#define DAO_CHECK_ERROR(f, err) AfxDaoCheck(f, NULL, NULL, 0, err)
#define DAO_CHECK_MEM(f) AfxDaoCheck(f, NULL, NULL, 0, \
NO_AFX_DAO_ERROR, TRUE)
#define DAO_TRACE(f) f
#endif
Anyways, I mentioned it in case you had included a macro in some header file that had something similar to a statement such as that, so your full file path was ending up as a static variable in every source file.
|
|
|
|
|
Thank you ...
Im not using Dao so I hope that last part of code does not apply to me. And I though that all asserts are turned off in Release version (through #ifdef _DEBUG) ... sigh, so looks like its hopeless
|
|
|
|
|
Hi I have a database..application..
I used CDatabase and CRecordSet to minipulate database.
the db has memo fields and i have no problem inserting the data using sql statement into db.. but when I try to get back.. by using while loop and recordset.movenext()to
get the data back.. I got the error message which is
"Data truncate".
example
<br />
while(!records->IsEOF())<br />
{<br />
..<br />
..<br />
records->MoveNext(); <----- get error on reading the record that has long string data. but indeed it was only 356words in it.<br />
}<br />
}
If I delete that data or shorten the data length.. I got no error..
why am i having error when I get the data back from database and why there is no error when inserting the same data?
|
|
|
|
|
Goto your CRecordset::DoFieldExchange member function.
Enlarge the buffer for text field exchange like:
RFX_Text(pFX, _T("[REMARK]"), m_REMARK,1000);
adjust the numer "1000" to your max characters of the corresponding field.
I remember the default max length for text field is 255, you would get the truncate error message if data length exceed it.
|
|
|
|
|
Anyone, help pls !!! Can I use a .dll file if I don't have the .h file ?
I saw some discutions on this subject, where it says that it is possible to generate the .lib file from a given .dll. OK, but then how could I know what are the parameters of the functions exported by that .dll ? 
|
|
|
|
|
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B131313[^]
I seem to remember steps for doing this being available at the SQLite web site also, may wanna check that place out in the FAQ or something...I just quickly looked and couldn't find it, but i'm sure something is there about how to do this...however i'm not sure about the header file...
HTH
I wonder if there are any animals that actually have to think in order to breathe? It would really suck to be them!!!
|
|
|
|
|
Thx, the article from microsoft is enough for me ... But what about those freakin' animals ?
Q: why a blonde died when her headphones were removed ?
A: cause she was hearing: now inhale, now exhale, now inhale, now exhale ...
|
|
|
|
|
Hi guys,
I have been trying to resolve this for a couple of days already. I hope someone out there will be able to help me out here.
Introduction:
I created a "wrapper" executable, which "implements" interface required to be run as windows service. This executable has set of configuration files, which are used to prepare environment and define another binary to be run as a service.
So the wrapper - during its own start-up - creates a new process from those configuration files.
Problem:
The starting and stopping works fine, but when I start the service from some user context (Administrator) and then I log off, the child process is being killed and my service wrapper detects that and stops.
The service configuration uses LocalSystem as the user context.
The weird part is that if I do this through a RDP connection, the child process stays alive even after logoff.
Snippet:
memset(&si, 0, sizeof(STARTUPINFO));
si.cb = sizeof(STARTUPINFO);
si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;
si.lpDesktop = "";
si.hStdOutput = hChildStdOut;
si.hStdInput = hChildStdIn;
si.hStdError = hChildStdErr;
BOOL ok = CreateProcess(NULL, lpszCmd, NULL, NULL, TRUE, // handles inherited
CREATE_NEW_CONSOLE | CREATE_NEW_PROCESS_GROUP , NULL, lpszPath, &si, piProcInfo);
Thanks in advance,
Peter
|
|
|
|
|
I think because you are creating your program attached to the current users's desktop, when the user logs off, your main window is terminated because the desktop is destroyed. Isn't there a hidden desktop that the services use? Perhaps you should attach to that instead.
|
|
|
|
|
Hi Blake,
thanks for your response...
You're probably referring to this part:
si.lpDesktop = "";
I tried to use lpDesktop with NULL value as well, and the child process was supposed to inherit the desktop from the parent process. However that did not work either...
Thanks,
Peter
|
|
|
|
|
What I meant was that the lpDesktop would NOT be NULL or EMPTY. It needs to be set to the name or handle of the desktop where the services are run. Any windows started on the desktop of the user are going to recieve all sorts of messages about termination when the user logs off.
It is best, if possible, to write services that have NO USER Interface whatsoever. Interact with them via TCP/IP, local RPC, DCOM, memory mapped files, service control commands, etc. Anything but windows!
|
|
|
|
|
Yes - I understood it correctly.
I was just saying that if you initialize STARTUPINFO.lpDesktop with NULL value desktop will be inherited (that's from MSDN).
So if the process which creates this child process is a service (that is my case), they should be on the same desktop, am I right?
My service has no user interface - it's plain process, which listens for the requests...
Thanks again,
Peter
|
|
|
|
|
I added a code, where I am quering the desktop of the current thread (running service wrapper) and retrieving its name. Then I used the retrieved desktop name for the new child process creation. It did not help. And the desktop name value retrieved in the code was "Default", which is weird I think...
code fragments:
HDESK hDesk = GetThreadDesktop(GetCurrentThreadId());
GetUserObjectInformation(hDesk, UOI_NAME, lpszDesktopName, ...);
...
si.lpDesktop = lpszDesktopName;
...
CreateProcess(..., &si, ...);
Thanks,
Peter
|
|
|
|
|
I am sorry now, I do not know what else to suggest 
|
|
|
|
|
I read an interesting article about a logon session broker written by K.Brown published @ MS site:
http://www.microsoft.com/msj/0200/logon/logon.aspx[^]
So I have done one more test and I used
Service-0x0-3e7$\\Default
as a value for DesktopName in STARTUPINFO, but it did not help either. My child process still dies after session log-off.
Thanks,
Peter
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
