|
in function after writing return();
is it possible to continue process will it be effective ?
|
|
|
|
|
maibam debina wrote: in function after writing return();
is it possible to continue process...
Not in that same function.
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
I have 2 dlls where one is run time loaded (Run.dll) and calls the other(other.dll)
Also the application calls the other.dll as well.
Now the other.dll has a static variable in it that is only used in itself i.e internally to the dll which gets changed by one of it's functions.
At the start of the program I call a this function in the other.dll to set the variable but later on when I run time load the run.dll which calls the function in the other.dll the variable is not set.
I thought the any variables in the other.dll which is statically linked to the app and to the run.dll will only have one instance of itself in memory especially regarding the variables?
How can I solve it to ensure that the variable in other.dll is the same across the process?
I forget to mention that I'm using the windows api etc.
|
|
|
|
|
It's difficult to visualise the actual sequence of events here, but it may be that on the second call into this dll it is getting reloaded somehow. Either that or there is another bug somewhere.
|
|
|
|
|
You wont be able to access anything in other.dll declared in such a way from Run.dll because they will have different instance handles. The only thing preventing a big crash in try to do so will be MFC's safe pointers because it is an access violation to allow it.
There are two ways around the problem provide a function that returns the status on a standard DLL interface function something like
int OtherDLLStatus (void) {
return (OtherDLLStaticVar);
};
Then publish it on the DLL interface and get the static variable status via that call. I think that is probably all you need.
However Option 2 is use shared memory mapping
http://msdn.microsoft.com/en-us/library/ms810613.aspx[^]
In vino veritas
|
|
|
|
|
Hi,
I am trying to call a MFC dialog based regular dll from other application. The dll function "BOOL CApplicationApp::InitInstance()" does not call to any dialog. I want to trigger UI on the click on button so i created a exported function which call first dilaog of application. But when I create a object of class it does load resource I think so crashed.
Suggest me how to do?
|
|
|
|
|
You could step into the exported function using a debugger to find what is going on.
MFC DLLs require the first line of a function to be - AFX_MANAGE_STATE(AfxGetStaticModuleState());
If you haven't done that, you could try by putting that as the first line of the exported function.
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
The short answer is between very difficult and you can't do this because not all of MFC is thread safe.
There are specific parts of MFC designed for threading general background
http://msdn.microsoft.com/en-us/library/975t8ks0%28v=vs.90%29.aspx[^]
The tips page will give you the specific problem
http://msdn.microsoft.com/en-us/library/h14y172e%28v=vs.90%29.aspx#_core_accessing_mfc_objects_from_non_2d_mfc_threads[^]
QUOTE:
If you have a multithreaded application that creates a thread in a way other than using a CWinThread object, you cannot access other MFC objects from that thread. In other words, if you want to access any MFC object from a secondary thread, you must create that thread with one of the methods described in Multithreading: Creating User-Interface Threads or Multithreading: Creating Worker Threads. These methods are the only ones that allow the class library to initialize the internal variables necessary to handle multithreaded applications.
In vino veritas
|
|
|
|
|
Hi i am doing a program with a clistctrl with custom draw and i have custom highlight color bar.
Now my problem is when i am with mouse on CListCtrl the bar is color i wish, when i leave to go on other control
i don't know how change the color in gray of the highlight bar, i post the code for you:
void CPubFoldersView::OnNMCustomdraw(NMHDR *pNMHDR, LRESULT *pResult)
{
NMLVCUSTOMDRAW* pCD = (NMLVCUSTOMDRAW*)pNMHDR;
int nRow = pCD->nmcd.dwItemSpec;
CListCtrl& m_MainTable = GetListCtrl();
CString szInEvidence;
pCD->nmcd.uItemState = CDIS_DEFAULT;
if (VirtualRowArray.GetCount())
szInEvidence=VirtualRowArray[nRow].Field[4];
switch(pCD->nmcd.dwDrawStage)
{
case CDDS_PREPAINT:
*pResult = CDRF_NOTIFYSUBITEMDRAW;
break;
case CDDS_ITEMPREPAINT:
*pResult = CDRF_NOTIFYSUBITEMDRAW;
break;
case CDDS_ITEMPREPAINT|CDDS_SUBITEM:
{
if (m_MainTable.GetItemState(nRow, LVIS_SELECTED)==LVIS_SELECTED && m_MainTable.GetItemState(nRow, LVIS_FOCUSED)==LVIS_FOCUSED)
{
pCD->clrTextBk = RGB(167,205,240);
*pResult = CDRF_NEWFONT;
}
if (m_MainTable.GetItemState(nRow, LVIS_SELECTED)==LVIS_SELECTED && m_MainTable.GetItemState(nRow, LVIS_FOCUSED)!=LVIS_FOCUSED)
{
pCD->clrTextBk = RGB(197, 206, 216);
*pResult = CDRF_NEWFONT;
}
}
break;
default:
*pResult = CDRF_DODEFAULT;
}
}
|
|
|
|
|
Perhaps I misunderstand your problem, but it sounds like all you are missing is to check if the list control itself has focus. If it does, you set the color as you are doing now, otherwise you set the gray color.
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
No i need to draw gray when i leave the row selected but i click on another control.
|
|
|
|
|
Right. In that case the other control has the focus, not the list control. Note, that this is different than a row within the list control having the focus state.
Your code for that could look something like this (I did not try to compile it so there might be errors):
case CDDS_ITEMPREPAINT|CDDS_SUBITEM:
{
if (::GetFocus() != m_MainTable.m_hWnd)
{
pCD->clrTextBk = RGB(192, 192, 192); *pResult = CDRF_NEWFONT;
}
else
{
if (m_MainTable.GetItemState(nRow, LVIS_SELECTED)==LVIS_SELECTED && m_MainTable.GetItemState(nRow, LVIS_FOCUSED)==LVIS_FOCUSED)
{
pCD->clrTextBk = RGB(167,205,240); *pResult = CDRF_NEWFONT;
}
if (m_MainTable.GetItemState(nRow, LVIS_SELECTED)==LVIS_SELECTED && m_MainTable.GetItemState(nRow, LVIS_FOCUSED)!=LVIS_FOCUSED)
{
pCD->clrTextBk = RGB(197, 206, 216); *pResult = CDRF_NEWFONT;
}
}
break;
}
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
|
|
|
|
|
You are a MASTER!!!! you solved me the problem THANKS THANKS!!!!
|
|
|
|
|
|
Hi everyone,
I am currently trying to read the following registry key in one of my programs:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultUserName
I need to find out whether automatic logon is enabled on a machine or not, and reading whether above setting is empty or not seems to be the best way to do this. However, querying the value simple returns an empty string (though it definitely isn't empty); the code is working, as it works fine with other keys. So I guess that my program, for whatever reason, cannot access the Winlogon keys (other keys also don't work).
Is there any workaround for this? Or any other way to find out if autologon is enabled? Hope anyone can shed some light on this, as it is driving me nuts right now 
I couldn't really find a better forum for this question; at least the program is written in C++, so... 
http://www.renderpal.com
http://www.shoran.de
|
|
|
|
|
Daniel 'Tak' M. wrote: as it works fine with other keys.
Daniel 'Tak' M. wrote: (other keys also don't work).
Which is it?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
The code works with other keys which are _not_ in Winlogon. Like HKLM\Software\Microsoft\Windows NT\CurrentVersion\Ports (read COM1:, retrieved the correct string).
http://www.renderpal.com
http://www.shoran.de
|
|
|
|
|
OK. You might want to post the code you are using. Maybe we can see something wrong with it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Here it is (pretty straightforward):
HKEY hKey;
if (RegCreateKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_READ, NULL, &hKey, NULL) == ERROR_SUCCESS)
{
BYTE lpBuffer[1024];
DWORD dwType;
DWORD dwBufferSize = 1024;
if (RegQueryValueEx(hKey, "DefaultUserName", 0, &dwType, lpBuffer, &dwBufferSize) == ERROR_SUCCESS)
{
...
}
}
The query succeeds, but the buffer is simply empty (though the setting isn't); if I change Winlogon to "Ports" and the key name to "COM1:", I get the correct value.
http://www.renderpal.com
http://www.shoran.de
|
|
|
|
|
Are you working with the 32 or 64 bit version of Windows?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
64 bit; the program is 32 bit, though.
http://www.renderpal.com
http://www.shoran.de
|
|
|
|
|
That might be the problem.
Try calling RegCreateKeyEx as such:
RegCreateKeyEx(HKEY_LOCAL_MACHINE, "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon", 0, NULL, REG_OPTION_NON_VOLATILE, KEY_READ | KEY_WOW64_64KEY, NULL, &hKey, NULL)
Use the KEY_WOW64_64KEY flag to indicate that you want to open the 64-bit view of the key.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
That did it! You really saved my day, Richard. My MSDN docs don't include that extra flag (VS 2005 still...), so I didn't know about it.
http://www.renderpal.com
http://www.shoran.de
|
|
|
|
|
Glad I could help. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Hi,
I've been using MFC Dev Studio 97 with VC 5++, MFC 42, etc for near 20 years, and it does exactly what I want it to do. In other words, I have absolutely no reason to fork out for an upgrade. The compiler and Wizards works fine under Windows 7.
One problem is that Win7 does not pass the 'Genuine Windows' test as soon as the program is installed on a Win7 computer. I know it is no longer supported. That however does not make it illegal to use! I paid big money for it at the time!
Another problem is, that the Help System fails to display anything. That started with XP SP 2, which could then be fixed with a Registry Setting relating to MK_PROTOCOL. XP-SP3 stripped away more help files.
At the moment, we have several Win98 computers running just to access the Help Files.
However There must be a better solution.
Regards,
Bram.
Bram van Kampen
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
