|
How does CMemFile store its data? Most likely it stores a pointer to the memory that contains the actual data. Look in the Microsoft documentation for CMemFile to see how it stores the data. Hopefully, CMemFile has a method to provide this pointer. An LPCSTR is a pointer to a string, so method could be called and the result could be cast to an LPCSTR if it is not already returned that way. Then this could be provided to the ShellExecute function.
David Spain, C++ Applications Programmer
|
|
|
|
|
David Spain wrote:
How does CMemFile store its data? Most likely it stores a pointer to the memory that contains the actual data. Look in the Microsoft documentation for CMemFile to see how it stores the data. Hopefully, CMemFile has a method to provide this pointer. An LPCSTR is a pointer to a string, so method could be called and the result could be cast to an LPCSTR if it is not already returned that way. Then this could be provided to the ShellExecute function.
I don't think so. You might obtain the CMemFile data using Detach, which returns a BYTE* and also closes the file. The return type is a BYTE* because a file may contain any type of data, not just text. Casting it to an LPCTSTR makes no sense: it may fool the compiler into accepting it, but the content will still be the same, and if it wasn't text, no one interpreting it as such will have correct results. In this case, in fact, it's an executable (binary) file.
Besides, ShellExecute expects to receive the name of the file path and name, not the content of the file.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Jose Lamas Rios wrote:
I don't think so. You might obtain the CMemFile data using Detach, which returns a BYTE* and also closes the file. The return type is a BYTE* because a file may contain any type of data, not just text. Casting it to an LPCTSTR makes no sense: it may fool the compiler into accepting it, but the content will still be the same, and if it wasn't text, no one interpreting it as such will have correct results. In this case, in fact, it's an executable (binary) file.
You are right. What I wrote actually made no sense. Obviously the ShellExecute function wants a string pointer, that points to the name of an actual file on disk.
As simply another idea, an executable in memory seems similar to a running process. Would using CreateProcess or something similar be a better avenue to pursue instead of ShellExecute?
David Spain, C++ Applications Programmer
|
|
|
|
|
Hi all,
I need to authenticate myself to a proxy. I have the domain\username and password.
I set it like this:
<br />
InternetSetOption((HINTERNET)(*pHttpFile), INTERNET_OPTION_USERNAME, <br />
sUsername, sUsername.GetLength());<br />
InternetSetOption((HINTERNET)(*pHttpFile), INTERNET_OPTION_PASSWORD, <br />
sPassword, sPassword.GetLength());
However, I still get the 407 error code.
Any idea how to set username and password for a file when behind a proxy?
Thanks!
Geert
Want to spread the newest version of your software automatically? Use Updater!
Visit my website: www.gvhsoftware.org
|
|
|
|
|
I am trying to get a rebar added to an existing MDI window, I am using the following code:
<br />
INITCOMMONCONTROLSEX icex;<br />
<br />
icex.dwSize = sizeof(INITCOMMONCONTROLSEX);<br />
icex.dwICC = ICC_COOL_CLASSES|ICC_BAR_CLASSES;<br />
InitCommonControlsEx(&icex);<br />
<br />
HINSTANCE hInst = (HINSTANCE)GetWindowLong(hParentHandle, GWL_HINSTANCE);<br />
hToolbar = CreateWindowEx(WS_EX_TOOLWINDOW,REBARCLASSNAME,NULL,WS_VISIBLE | WS_BORDER | WS_CHILD | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | RBS_VARHEIGHT | RBS_BANDBORDERS | CCS_NODIVIDER | CCS_NOPARENTALIGN,0,0,0,0,hParentHandle,NULL,hInst,NULL);<br />
if( !hToolbar ) {<br />
MessageBox(0, "Could not create toolbar control", "Error", MB_OK | MB_ICONHAND);<br />
return;<br />
}<br />
<br />
SetWindowLong(hWndBar, GWL_STYLE, WS_VISIBLE | WS_CHILD | TBSTYLE_TOOLTIPS | CCS_NOPARENTALIGN | CCS_NORESIZE);<br />
SetWindowPos(hWndBar, 0, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);<br />
<br />
RECT rect;<br />
GetWindowRect (hWndBar, &rect);<br />
<br />
REBARINFO rbi;<br />
rbi.cbSize = sizeof(REBARINFO);<br />
rbi.fMask = NULL;<br />
SendMessage(hToolbar, RB_SETBARINFO, 0, (LPARAM)&rbi);<br />
<br />
REBARBANDINFO rbb;<br />
rbb.cbSize = sizeof(REBARBANDINFO);<br />
rbb.fMask = RBBIM_SIZE | RBBIM_CHILD | RBBIM_CHILDSIZE | RBBIM_ID | RBBIM_STYLE | RBBIM_TEXT | 0;<br />
rbb.hwndChild = hWndBar;<br />
rbb.cxMinChild = rect.right - rect.left + 2;<br />
rbb.cyMinChild = rect.bottom - rect.top + 2;<br />
rbb.cx = 250;<br />
rbb.fStyle = RBBS_BREAK | RBBS_GRIPPERALWAYS;<br />
rbb.wID = 100085;<br />
rbb.lpText = TEXT("Toolbar");<br />
<br />
SendMessage(hToolbar, RB_SETPARENT, (WPARAM) (HWND) data->hParentHandle, (LPARAM)0);<br />
SendMessage(hToolbar, RB_INSERTBAND, (WPARAM)-1, (LPARAM)&rbb);<br />
SendMessage(hToolbar, RB_SHOWBAND, (WPARAM)(UINT)0, (LPARAM)(BOOL)TRUE);<br />
SetWindowPos(hToolbar, 0, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_FRAMECHANGED);<br />
Now using that code, the bar appears to flash on the screen but doesn't stay there, what am I missing?
|
|
|
|
|
Hi,
I have one executable say program.exe which is linked with first.dll.
first.dll contains TestClass. Now if i replace the first.dll with the
dll of same name and same exported function of class TestClass, but
having different implimentation, then the program.exe is executed with
replaced first.dll.
Is there any way to know that the first.dll is replaced or not.
Regards
AbdulMunaf Chhatra
Software Engineer,
C-Sam Solutions Pvt. Ltd.
Phone : +91-265-2324018/19
Email : a.chhatra@popnet.co.in
|
|
|
|
|
Abdul Munaf Chhatra wrote:
Is there any way to know that the first.dll is replaced or not.
How about looking for an exported function or global variable that exists only in the original DLL?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Here is something I did a long ago.
Create a global string in the DLL like
char* pCpde = "My Secret Code";
Before loading the DLL from the EXE, open the DLL in binay mode from the EXE.
Search for your secret code.
If it exists, close the DLL file and load it.
I call it signing code. 
« Superman »
|
|
|
|
|
If you look at MS Word, with a new blank document.. and then choose View->Print Layout menu.. Now, you'll see the white page on the brown/gray background.. on a 100% view
I know that on normal circumstances in Doc/View architecture, the client area of CView entirely occupies the client area of the CCHildFrame..
Now with the Print-Layout View, Is it possible that the white page is drawn on the CView client area but it is NOT occupying the whole client area of CCHIldFrame so thats why we are seeing the background color of CChildFrame?
Or is the white page and the background color are all drawn together in the client area of CView?
Maverick
"watch the birdie!..."
|
|
|
|
|
I used Spy++ and using the window finder tool suggests that the 'white paper' that you see is a window that is not part of the background that the paper 'sits' on.
I'd be surprised to learn that the MFC document/view classes are in use in Word.
Chris Meech
I am Canadian. [heard in a local bar]
Remember that in Texas, Gun Control is hitting what you aim at. [Richard Stringer]
Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
|
|
|
|
|
so u're saying that Doc/View classes aren't used in Word?
|
|
|
|
|
Maverick wrote:
so u're saying that Doc/View classes aren't used in Word?
Maybe they use some Doc/View classes, but most likely not MFC's CDocument and CView
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I am trying to create a CDialogBar from an existing window using the Attach() method (I have to use Attach because the window is created by a seperate process belonging to my app), I also have a CMDIFrameWnd which I would like to dock the dialog bar to, I am using this code:
<br />
data->m_pParent = new CMDIFrameWnd;<br />
if( !data->m_pParent->Attach(data->hParentHandle) ) {<br />
ShowError();<br />
return;<br />
} else {<br />
MessageBox(0, "Attached OK", "Attach", MB_OK);<br />
}<br />
<br />
SetWindowLong(hWndBar, GWL_STYLE, WS_CHILD | CBRS_LEFT | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY);<br />
<br />
data->m_pBar = new CDialogBar;<br />
if (!data->m_pBar->Attach(hWndBar) )<br />
{<br />
ShowError();<br />
return;<br />
}<br />
<br />
data->m_pBar->EnableDocking(CBRS_ALIGN_ANY);<br />
data->m_pParent->EnableDocking(CBRS_ALIGN_ANY);<br />
But I get a failed assertion on this line in dockcont.cpp
<br />
ASSERT(pBar->m_pDockSite != NULL);<br />
Am I even heading in the right direction here?
Thanks in advance
|
|
|
|
|
Hi,
I have code like in this manner to split the pane that will have 2 rows and 1 column.
VERIFY(m_wndSplitter.CreateStatic(this, 2, 1));
VERIFY(m_wndSplitter.CreateView(0, 0, RUNTIME_CLASS(SmallClass), CSize(100,100), pContext));
VERIFY(m_wndSplitter.CreateView(1, 0, RUNTIME_CLASS(BigClass), CSize(100,100), pContext));
This always displays two panes.
Now my task is to find out at run time and display only one pane, but when I changed the code
VERIFY(m_wndSplitter.CreateStatic(this, 1, 1));
I am getting an assertion stating that either maxCol or maxRow should be greater than 1 in winsplit.cpp.
Can somebody help me out to display one pane/ two panes and decide about this at run time?
Thanks,
PRJ
|
|
|
|
|
|
i need to access the toolbar which is created in the parent window from the child window. but i m unable to do so. what should be done? can any1 pliz suggest.
thanx in advance
|
|
|
|
|
How about using GetParent() to get the parent window and then accessing the toolbar using the parent window.
« Superman »
|
|
|
|
|
Santosh M. P. wrote:
How about using GetParent() to get the parent window
well, tried getparent() but how to get access to the toolbar after that. pliz help
|
|
|
|
|
Hi there,
I want to write a simple dialog based application that should access the internet and get me a file from the server on the web.
Not only that, but I also need to send a URL back to the server to update the database residing on it.
Any ideas on how to do it ?
From what I read, they say that CWebBrowser can do that, but for some reason I couldn't find the basic interfaces to the Document through the file MSHTML.DLL as they stated in MSDN. could it be that I am using an old ver ?
Anyway, I am just starting out, so I'll be glad to hear on your perspective
Thanx, N
|
|
|
|
|
|
Hello everyone,
Does anyone know where could I find open source OMA Device Management client?
thanks in advance,
George
|
|
|
|
|
Hallo,
I wrote a class to communicate via a serial interface. To initialize the communication I firstly setup the interface and open it with CreateFile(...), then I start one thread to send data and one to receive with AfxBeginThread(...). When trying to send data in the send thread, the thread crashes invoking WriteFile(...). This doesn't happen when I send it in the initialization function! So, how is it possible to access resources like a serial interface in a thread?
Best regards
Juergen
Juergen Kordes
|
|
|
|
|
Post the code which send data, it will help us a lot.
What I do generaly when I need to do these kind of things (also a class to communicate with serial interface), is to start two thread (one for sending, one for receiving) but that runs functions from the class itself. A short example to explain (imagine the class is called CSerial):
UINT SendProc( LPVOID pParam )<br />
{<br />
CSerial* pSerial = (CSerial*)pParam;<br />
pParam->SendFunc();<br />
}<br />
<br />
void CSerial::Start()<br />
{<br />
...<br />
...<br />
AfxBeginThread(SendProc,(LPVOID)this,....);<br />
}
The SendFunc is a public function of CSerial that is running an 'infinite' loop to send data. Like that you can control when the loop has to finish by settings a member variable of the class to false.
It is a much cleaner way of doing this: your handle to the serial port is contained in the class itself. But be carrefull to encapsulate it into CriticalSection (take a look at the MSDN if you don't know what it is). Othrwise you will have some problems.
Hope this helps
|
|
|
|
|
Sorry that I didn't express myself exactly. Let me briefly explain the class I used:
class SERIAL<br />
{<br />
...<br />
protected:<br />
static UINT SendQueueThread(LPVOID x);
static UINT PortReadThread(LPVOID x);
<br />
CWinThread* m_pPortReadThread;<br />
CWinThread* m_pSendQueueThread;<br />
<br />
public:<br />
bool PortInitialize(...);
HANDLE hComPort;
int send(BYTE IDByte,unsigned char* pFirstByte,int len);<br />
<br />
...<br />
};
Within the SERIAL :: PortInitialize(...) I do the following:
bool SERIAL::PortInitialize(...)<br />
{<br />
...<br />
hComPort=CreateFile ( portName,
GENERIC_READ | GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL );
<br />
<br />
if(hComPort==INVALID_HANDLE_VALUE)<br />
{<br />
...<br />
return false;<br />
} <br />
<br />
<br />
GetCommState(hComPort,&PortDCB);<br />
...<br />
SetCommState(hComPort,&PortDCB);<br />
<br />
GetCommTimeouts(hComPort,&CommTimeouts);<br />
...<br />
SetCommTimeouts(hComPort,&CommTimeouts);<br />
<br />
EscapeCommFunction(hComPort,SETDTR); <br />
EscapeCommFunction(hComPort,SETRTS); <br />
<br />
m_pSendQueueThread = AfxBeginThread( SendQueueThread, this );<br />
if( m_pSendQueueThread == (CWinThread*)0 )<br />
{<br />
displayWindowsError( "SERIAL::PortInitialize(...) Error starting SendQueueThread." );<br />
return( false );<br />
}<br />
else<br />
{ <br />
m_pSendQueueThread->SetThreadPriority(THREAD_PRIORITY_ABOVE_NORMAL );<br />
}<br />
<br />
...<br />
}
The sendthread contains the following code fragments:
UINT SERIAL :: SendQueueThread(LPVOID lpvoid)<br />
{<br />
...<br />
SERIAL *pSerial=(SERIAL*) lpvoid;<br />
BYTE ClassID,CommandID;<br />
int len;<br />
unsigned char *data;<br />
...<br />
ClassID=pSerial->m_pMessage->GetClassID();<br />
CommandID=pSerial->m_pMessage->GetCommandID();<br />
len=pSerial->m_pMessage->GetMessageLen();<br />
data=pSerial->m_pMessage->GetMessageString();<br />
test=pSerial->send(CommandID,data,len);<br />
<br />
...<br />
}
At least, the function SERIAL::send(...) contains the following code:
int SERIAL::send(BYTE IDByte,unsigned char* pFirstByte, int len)<br />
{<br />
...<br />
<br />
DWORD dwNumBytesWritten;<br />
char* buffer;<br />
buffer = new char[100];<br />
for( int i = 0; i < 99; i++ )<br />
buffer[i] = i + 48;<br />
buffer[99] = 0;<br />
<br />
try<br />
{<br />
DWORD strLen = strlen(buffer);<br />
WriteFile(hComPort,
(void*)buffer,
(DWORD)strlen( buffer ),
&dwNumBytesWritten,
NULL);
}<br />
catch ( CException *e )<br />
{<br />
...<br />
}<br />
<br />
delete [] buffer;<br />
<br />
...<br />
}
That's all! When calling WriteFile(...) in SERIAL::send(...) the thread crashes, as mentioned before.
Thanks for your help!
Juergen Kordes
|
|
|
|
|
Ok... Maybe this is due to the fact that the handle is currently used by the other thread (for reading) and thus crashes. I'm not sure but that could be a solution.
Maybe a solution to that is use CriticalSections to be sure that write and read won't access the handle at the same time.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
