|
lol, glad I could help 
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Is the program trying to create a new file, or open an existing file?
Did you try running the program "as administrator?"
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Open a new file.
And I am god on my laptop, so I don't think it's that. But, I've always used the properties option on the fileview to override the base settings. Made sure I was running as admin, run it in Xp mode, etc. No joy, same error.
The weird thing, again, is that the source code has not changed in over two years. A few weeks back, the app just came off the rails and started having these issues.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
charlieg wrote: A few weeks back, the app just came off the rails and started having these issues.
What's not clear is whether you have been running it on Win 7 for a long time before the issue appeared, or if the issue has always existed on Win 7.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Origin of this program has been Xp Pro. Up until a few weeks ago, it ran fine on W7; however, we pretty much use it on xp. When it started misbehaving on Xp, we tried it on W7, and on multiple machines of various OS flavors - same basic error.
Good point.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Does the issue appear only when trying to create the file in your special location, or in any location?
Have you tried creating a new file in the same location by other means, such as with Windows Explorer, or any other application?
Why not write a small test program in MFC that does nothing but try to open a file in that location?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Well, I can craft up a small mfc app to do the same basic thing - that's a good idea, and it may show the problem, I'll give it a shot. Doing so will exercise the same basic code flow as the base application.
As far as other tools, yes, we work in this basic area on a day to day basis.
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
After reading all the replies to this, the one thing that's clear is that you've never told anyone exactly where you are creating the file. All we know is that it's someplace on your C drive. Well, newer versions of windows (beyone XP) place restrictions on where you can create files on the system disk ( C: ) so we'll keep going in circles until you provide details beyond "fail" and "hidden place" and other obscure bits of information.
|
|
|
|
|
Per Chuck's comments, let me elaborate on the directory structure of where this app works. He has a point, given the W7 restrictions on random file locations.
The application in question works with a specific directory tree which we will call our release tree. The basic structure:
c:\release
folder A
folder B
etc.
It does not matter to the application where the release folder's root is. I could put it anywhere. Normally it lives on the C drive at the basic level, as it has for some time. Note even though the application runs both in W7 and Xp, I'm mainly worried about Xp. We've never had any issues with permissions, so don't let W7 distract you.
The application allows the user to specify the root folder, so he selects C:\release. When the app runs, it's crunching files in the c:\release tree. Sometimes, it needs to create working files - in c:\release. Sometimes it can, and sometimes it cannot... it is very random. It I go to that folder, I can create files to my heart's content, so I don't think it is a permissions issue.
What else am I being ambiguous about.?
Charlie Gilley
<italic>You're going to tell me what I want to know, or I'm going to beat you to death in your own house.
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I would attempt to create a separate application that does nothing but open the file in question. Build upon that until the problem re-appears.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
|
|
|
|
|
hi all
can any one pleas e help me to read and write struct using CArchive file.
thanks.
|
|
|
|
|
|
See also  :
void TestExchange(CArchive& ar, POINT& pt)
{
if (ar.IsStoring()) {
ar.Write(&pt, sizeof(POINT));
} else {
ar.Read(&pt, sizeof(POINT));
}
}
They sought it with thimbles, they sought it with care;
They pursued it with forks and hope;
They threatened its life with a railway-share;
They charmed it with smiles and soap.
|
|
|
|
|
I have a dialog CTest.
I have placed a edit control m_Edit1
In the dialog CTest.CPP file I have created a thread with a global function void Update()
I need this global function to update the value of m_Edit1 every cycle in the thread. Since m_Edit1 is a Class member, I unable to access the member variable inside the global function.
Please provide me all the possible alternatives to access a member variable and member function from a global function.
|
|
|
|
|
You can only access the variable through the object, so you need to send a pointer to the object into the global function. Perhaps you need to look at your design.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
I used a global pointer to the dialog class. I initialized the global pointer to "this" pointer inside the OnInitDialog() function. Then I used the global pointer in the global function to call the member function. The member function is called, but when I try to update values in the edit control using UpdateData(FALSE) the application crashes.
|
|
|
|
|
You mentioned that you are using another thread. MFC classes are not thread safe. To communicate with Windows controls from another thread, use the API PostMessage() function in your thread passing the handle of the control window. Alternatively post user defined messages and handle them in your CDialog derived class.
|
|
|
|
|
|
Hi,
I am getting a CInvaliArg exception after Doing CWnd::SendMessage
The CWnd is a CDialog
The Wparam and Lparam are both pointers
The ONMESSAGE procedure has WPARAN LPARAM paramters
What Causes a CInvalid Arg Exceptions ??
|
|
|
|
|
You could try stepping into the SendMessage function to see what causes it to bomb.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Without seeing the exact code no one can guess what you are doing wrong.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Durning The INITINSTANCE of my CWinApp I allocate via new operator a Derived CEvent class
This CLass has
1) buffer allocated via new in the contructor of a command that I use via named pipes
"WriteFIle" to get excuted in another process
2) a pointer to a CWND * type object for which I do ::SendMessage(
of the responce of that command
I use SetEvent to trgger the Write file with the contents of what is in the buffer
In My case the CWnd * is a CDialog * but that shouldn't be a problem
The corruption ??? if I allocate via new in the ::INITINSTANCE of My Main Thread
that object (derived CEvent) it should remain there for the lifetime of the prrocess
I save the pointer to that object In My main thread reterive that pointer
via AfxGetApp
|
|
|
|
|
Very interesting but you need to show the exact code that causes the problem, including the code that creates any objects used in the line causing the problem. Explaining in broad terms as above does not really help.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
In My CWinApp:: InitInstance() I create a Derived CEventObject
mybaseeventptr = new MyBaseEvent(FALSE,FALSE,NULL,NULL); which has the following layout
class MyBaseEvent : public CEvent
{
public:
MyBaseEvent(); MyBaseEvent(BOOL own, BOOL reset, LPCTSTR mystring, LPSECURITY_ATTRIBUTES mysec);
char *buffer_ptr;
int len;
CWnd *send_window;
};
then further down in my CWInApp::InitInstance I create a worker thread which does
WriteFile and ReadFile (named pipes IPC)
this is triggered via SetEvent from my derived MyBaseEvent Object
In Addition to triggering the event I set the CWnd * pointer of the Window were I would like the message sent to
LRESULT CprogDebug::receive_tcpip(WPARAM mywparam,LPARAM mylparam) {
UNREFERENCED_PARAMETER(mywparam);
char *hold_ptr;
CHERC_CMDApp *main_app;
MyBaseEvent* myeventptr;
.
.
.
.
myeventptr->send_window = this;
myeventptr->SetEvent(); return TRUE;
}
The following is the worker thread I started which has the SendMessage causing the
exception
UINT hercgui_commands(LPVOID lparam)
{
int i;
CString storstrg;
BOOL bresult;
UNREFERENCED_PARAMETER(lparam);
void SetThreadName( DWORD dwThreadID, LPCSTR szThreadName);
CMutex mymutex(FALSE,"HercLock",NULL);
CSingleLock HercLock(&mymutex);
DWORD dwbytestoread;
CHERC_CMDApp* main_app;
CMainFrame *main_window;
dwbytestoread = 1500;
MyBaseEvent *my_event;
main_app = (CHERC_CMDApp *)AfxGetApp();
my_event = main_app->mybaseeventptr;
SetThreadName(GetCurrentThreadId(),"HercGUI");
while(1)
{
WaitForSingleObject(my_event->m_hObject, INFINITE);
if (!HercLock.IsLocked())
{
HercLock.Lock(INFINITE);
WriteFile(main_app->filehdl,
(LPCVOID)my_event->buffer_ptr,
30,
NULL,
(LPOVERLAPPED) &main_app->herc_over);
}
bresult = ReadFile(main_app->filehdl,
(LPVOID) my_event->buffer_ptr,
dwbytestoread,
NULL,
(LPOVERLAPPED) &main_app->herc_over1);
WaitForSingleObject(main_app->herc_over1.hEvent,INFINITE);
HercLock.Unlock();
my_event->send_window->SendMessage(WM_HERCGUI_MESS,(WPARAM) my_event->len,(LPARAM) my_event->buffer_ptr);
i = 1;
}
return 0;
}
Maybe the problem is passing pointer objects across threads ?? as maybe I should just
pass the handle of the CWnd *
Thsnks
|
|
|
|
|
ForNow wrote: Maybe the problem is passing pointer objects across threads ?
I think that is true, the SendMessage() function actually calls in to the window procedure of the main thread which is illegal. You should use the PostMessage() function which sends the message into the main thread's message queue.
One of these days I'm going to think of a really clever signature.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
