|
Here is the code which has been pared down a bit to get rid of unrelated initialization:
(one note: this routine itself was started as a thread so it is second in line and is trying to start a third thread.)
unsigned __stdcall micro_main(void *dummy)
{
unsigned threadID;
//other unrelated code
PSECURITY_DESCRIPTOR pSD;
SECURITY_ATTRIBUTES sa;
pSD = (PSECURITY_DESCRIPTOR) LocalAlloc( LPTR, SECURITY_DESCRIPTOR_MIN_LENGTH);
if (pSD == NULL)
{
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,NULL, GetLastError(),MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(LPTSTR) &lpMsgBuf,0,NULL );
MessageBox( NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION );
LocalFree( lpMsgBuf );
}
if (!InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION))
{
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,NULL, GetLastError(),MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(LPTSTR) &lpMsgBuf,0,NULL );
MessageBox( NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION );
LocalFree( lpMsgBuf );
}
if (!SetSecurityDescriptorDacl(pSD, TRUE, (PACL) NULL, FALSE))
{
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,NULL, GetLastError(),MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(LPTSTR) &lpMsgBuf,0,NULL );
MessageBox( NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION );
LocalFree( lpMsgBuf );
}
sa.nLength = sizeof(sa);
sa.lpSecurityDescriptor = pSD;
sa.bInheritHandle = TRUE;
MICRO_THREAD_SUB = (HANDLE)_beginthreadex( &sa, 0, &sub_main_MACRO_CONTROL, NULL, 0, &threadID );
if (MICRO_THREAD_SUB == 0)
{
// it is here that that I always get the error
LPVOID lpMsgBuf;
FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS,NULL, GetLastError(),MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),(LPTSTR) &lpMsgBuf,0,NULL );
MessageBox( NULL, (LPCTSTR)lpMsgBuf, "Error", MB_OK | MB_ICONINFORMATION );
LocalFree( lpMsgBuf );
}
else
{
WaitForSingleObject(MICRO_THREAD_SUB,INFINITE);
CloseHandle(MICRO_THREAD_SUB);
}
// _endthreadex(0);
}
/*this is the thread which is called which immediately calls another thread-could that char com[200000]; be part of the problem? (it was used for some early debugging and no longer has any functionality.*/
unsigned __stdcall sub_main_MACRO_CONTROL(void *dummy)
{
char com[200000];
Run_Parser_Simulation(Sim->MACRO);
// _endthreadex(0);
return 0;
}
Thanks for looking at this. Regards,
Jay
|
|
|
|
|
There is quite a bit going on in the code including the call to LocalAlloc().
pSD = (PSECURITY_DESCRIPTOR) LocalAlloc( LPTR, SECURITY_DESCRIPTOR_MIN_LENGTH);
Try passing in __beginthreadex() default parameters, i.e. NULL, etc. to make sure the callback function is valid.
Kuphryn
|
|
|
|
|
Kuphryn,
Thanks for your answer. I brought in the PSECURITY_DESCRIPTOR code as a response to the memory allocation errors. Before that I used _beginthreadex() without default parameters. The problem is that the memory allocation errors only occur intermittantly and in what seems to be an unreproducible manner.
Jay
|
|
|
|
|
Or is it a deadlock somewhere?
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
What do you mean by a deadlock?
Regards,
Jay
|
|
|
|
|
thread A holding resource A and waiting for resource B
thread B holding resource B and waiting for resource A
Causing infinite waiting for resources of both threads.
Check out multithreading management topic.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
Anthony,
That is not quite the logic I am using. It is:
thread A launches thread B and continues on so that GUI is responsive
thread B launches thread C and waits for thread C to finish.
This should be o.k., I think.
Jay
|
|
|
|
|
i am using a visual studio add in.
in one of the methods i am using
CWinApp* pApp = AfxGetApp();
i need to get a pointer the visual studio app, not the add in app,
in both cases, even if i use or don't use
AFX_MANAGE_STATE(AfxGetStaticModuleState())
i get a pointer to the add in app
and not the pointer to the visual studio (exe)
how can i retrieve the pointer to the visual studio exe???
thanks
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
im not very experienced in add in´s - would FindWindow() or FindWindowEx() help?
|
|
|
|
|
nop, not in this matter....
(thanks anyway)
any other suggestions?
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
Is this a VS.NET or a VC 6 add-in?
|
|
|
|
|
VC 6
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
Wouldn't you just use the IApplication pointer that gets passed to IDSAddIn::OnConnection?
|
|
|
|
|
my original problem was how to get the *.dsw file.
i saw a code that does that :
CString CCommands::GetWorkspacePath()
{
CWinApp* pApp = AfxGetApp();
ASSERT(NULL != pApp);
CString szWorkspace(_T(""));
POSITION posdt = pApp->GetFirstDocTemplatePosition();
while (NULL != posdt)
{
CDocTemplate* pdt = pApp->GetNextDocTemplate(posdt);
if (0 == strcmp("CProjectWorkspaceDocTemplate",
pdt->GetRuntimeClass()->m_lpszClassName))
{
POSITION posdoc = pdt->GetFirstDocPosition();
if (NULL == posdoc)
break;
CDocument* pdoc = pdt->GetNextDoc(posdoc);
if (NULL == pdoc)
break;
szWorkspace = pdoc->GetPathName();
if (!szWorkspace.IsEmpty())
break;
}
}
return szWorkspace;
}
trouble was that when i run this code i got NULL for this line:
POSITION posdt = pApp->GetFirstDocTemplatePosition();
that's what led me to think that the pApp is the dlls therefor it can not get the doc template (cause it doesn't have one) what it should be is the dev studio exe and have a doc template.....
can you help me here? i am really desperate no one could help me here...
thanks again
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
Yaron,
While I'm not sure exactly what you're trying to accomplish, it seems to me that using the DocView hierarchy exposed by DevStudio rather than its automation interface is way more work than its worth.
The IApplication pointer that gets passed to OnConnection is a pointer to the DevStudio instance in which your add-in is running. It includes an entire COM object hierarchy that allows you navigate windows, projects, files, etc.
Look for IApplication in the DevStudio version of MSDN (not the newer MSDN that comes with VS.NET). It's got an easily navigable hierarchy that should get you where you need to be.
don
|
|
|
|
|
I know the this heirarchy, already read the MSDN,
the thing i try to accomplish is when i open a project in the dev studio then usign my add-in i want to get the entire path of the *.dsw file....
i could not find any code for doing that (getting the *.dsw file)
can you help?
thanks again
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
What does Application::ActiveProject::FullName return?
|
|
|
|
|
it returns the *.dsp name of the active project....
i can not just do concatonation like this
ProjectName.dsp --> ProjectName. --> ProjectName.dsw
because it is not insured that the name of the dsw is the name of the active project.....
"help i need sombody , help is there anybody, help you know i need some HHHEEEELLLPPP"
thanks again
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
OK, one last idea and then I'm out of suggestions:
Have you tried looping through the Application::Documents collection looking for a file with the dsw extension?
|
|
|
|
|
this i haven't tried yet, so i will try it now, but my guess is that the documents collection is empty at this stage.....but i will sure try it now and let you know
thanks for all the trouble
cheers,
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
YaronNir wrote:
i need to get a pointer the visual studio app, not the add in app,
What you describe is the difference between a MFC regular DLL and an MFC extension DLL. An extension DLL uses the CWinApp of the EXE, so that's the type of DLL you need to use.
--Mike--
Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber
There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
|
|
|
|
|
thanks for the reply,
but when i start a visual studio add in project (using the wizard) , what options do i have???? it determines for me the type of dll it produces....
how can i bypass it?
thanks again
Yaron
Ask not what your application can do for you,
Ask what you can do for your application
|
|
|
|
|
 Hi,
I have created Browser Helper Object(BHO) to get and handle events triggered by "Internet Explorer"(IE).
I am albe to intercept events of IE like DocumentComplete etc. Even I am getting the submit event of the form when "submit" button is clicked. But I am not been able to stop the form being submitted. May be because of when I get the submit event of the form meanwhile somebody other who is responsible for submitting the form is submitting it.(by using POST or GET method, may be browser itself is submitting the form)
Now the problem is by intercepting which event of whom i.e. of IWebBrowser2 or HTMLFormElements or any other Interface can I stop the submition of form.
I actually want to know which event is triggered, that can be caught in IDispatch::Invoke of my BHO, when form(html form) is sent to server(by POST or GET method).
Avinash D.J.
|
|
|
|
|
You can't stop the form from being submitted. You are responding to a notification that the form *has* been submitted.
|
|
|
|
|
As Terry has already pointed out, an event signalizes in this case that something has already taken place, and you cannot influence the trigger of the event in the past.
However there is a workaround, and it is called API hooking/hijacking/monitoring.
Internet Explorer uses the Wininet functions to communicate with the internet. If your user clickes the "go" button with some url in the address bar, the appropriate Wininet functions, like HttpOpenRequest and HttpSendRequest are called inside IE's code. The same applies to when the user submit a form.
If you hook into the WinInet functions from your BHO, then you will be able to monitor and "authorize" IE's actions.
Example: if your user clicked a Submit button on a form with POST action then HttpOpenRequest is called with the second parameter lpszVerb being "POST". You can take any action including stopping the process.
If a form with "GET" action is concerned, your job is a bit more difficult because the verb in this case does not differ from "ordinary" page requests. You could then take into account the url from your form, and compare it with lpszObjName (3. param of HttpOpenRequest)
If you are unfamiliar with API hooking, check out this article:
http://www.codeproject.com/useritems/api_monitoring_unleashed.asp
Peter Molnar
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
