|
See the documentation[^] for the valid responses from this function.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
yes , i know but why just with Acrobat reader i don't get the GetClipBoardOwner ?
|
|
|
|
|
What does GetLastError() tell you?
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
GetLastError() gives me 0 as result only with acrobat reader
|
|
|
|
|
Sorry, no idea. If it does not give any useful information one can only guess that Acrobat is doing something different.
Binding 100,000 items to a list box can be just silly regardless of what pattern you are following. Jeremy Likness
|
|
|
|
|
Yes that's why i opened this thread , this just with acrobat reader ! really strange
I hope someone will help me in this issue
|
|
|
|
|
randydom wrote: ...but when using it with acrobat reader i don't get any result .
What exactly do you mean by this?
Just because the clipboard contains data does not also mean it is owned.
"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,
I have following C code and I am trying to measure time used by CPU.
timespec time1, time2, temp_time;
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time1);
long cpu_sum = 0;
for (i = 0; i < nelements; i++) {
cpu_sum += array[i];
}
clock_gettime(CLOCK_PROCESS_CPUTIME_ID, &time2);
int borrow = 0;
long n = time2.tv_nsec - time1.tv_nsec;
if (n < 0) {
n += 1000000000L;
borrow = 1;
}
temp_time.tv_nsec = n;
temp_time.tv_sec = time2.tv_sec - time1.tv_sec - borrow;
printf(calculated sum: %d using CPU in %lld.%.9ld seconds \n",taskid, cpu_sum, (long long)temp_time.tv_sec, (long)temp_time.tv_nsec);
Just wondering how can i get time in milliseconds?
|
|
|
|
|
It's pretty simple, really. One second is 1000 milliseconds. One millisecond is a million nanoseconds. So
millisecs = secs * 1000 + nanosecs / 1000000 What's so hard about that, given you already have the seconds and nanos?
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Thanks for reply. I am not sure whether my timing calculations mentioned above are correct?
|
|
|
|
|
Looks OK at a quick glance. The only problem I can see immediately is too many parameters for the format string in the printf.
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Well I figured out how to test my compiled output, and find most of the errors.
This is the heart of most of my program failures, and strange behavior. It has something to do with Threads.
On one example, I have a dialog box, that loads parameters. I then click OK, and run the validator, first creating a thread, and the validator runs in the thread, which produces strange errors, like not connecting to sql server.
If I dump the thread, and just run the code function, it works fine, no problem. So I have to decide whether to dump the threads, or try to fix them.
I've tried WaitForSingleObject, and now the MsgWaitForMultipleObjects. On the latter, it just crashes on check return code, in which I run a MessageBox, and crashes.
I am posting this to see if perhaps it just needs improvement. It crashes on Case 1:, but I'm not sure if it really has a problem there or not. The message is Access violation reading location 0x2102fe2b. I don't have the expertise to proceed with the message.
DWORD dwRet;
do {
dwRet = ::MsgWaitForMultipleObjects( 1, &hThread, FALSE, INFINITE, QS_ALLEVENTS );
if (dwRet != WAIT_OBJECT_0)
{
MSG msg;
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
} while ((dwRet != WAIT_OBJECT_0) && (dwRet != WAIT_FAILED));
DWORD dwExitCode = 0;
if ( GetExitCodeThread( hThread, &dwExitCode ) ) {
CloseHandle( hThread );
switch ( dwExitCode ) {
case 0:
bReturn = TRUE;
break;
case -1:
{
SetFocus( ddl_ProjectCreate_DatabaseName_Field );
SendMessage( ddl_ProjectCreate_DatabaseName_Field, CB_SETCURSEL, (WPARAM) 0, (LPARAM) 0 );
}
break;
case 1:
MessageBox( g_hWndMainFrame, TEXT("You must select a project type to create\0"), TEXT("Create Project\0"), MB_OK );
SetFocus( lv_ProjectCreate_ProjectType );
break;
|
|
|
|
|
What does your secondary thread do? Show some code if possible. On a sidenote, you mentioned setting strange errors from the thread like not connecting to sql, do you use COM for this? You might need to initialize COM with CoInitializeEx[^] in every thread that does some COM operations (i remember running into this once), did you do this?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I'm using ODBC to connect to the sql server.
The dialog box runs 1 thread to validate when you press OK, and then the next thread to create the project, in which it copies files to the folder, sets permissions, creates a database and tables, users, permissions, write to the registry, and then opens the project.
The strange behavior on the SQL, is that the first sql function runs correctly, and then the 2nd one won't connect.
This is the sql function
BOOL bResult = FALSE;
SQLHENV henv;
SQLHDBC hdbc;
SQLHSTMT hstmt;
SQLRETURN retcode;
SQLWCHAR OutConnStr[1024];
SQLSMALLINT OutConnStrLen;
HWND desktopHandle = GetDesktopWindow();
SQLWCHAR szDatabaseExist[80];
SQLLEN cbDatabaseExist = 0;
retcode = SQLAllocHandle(SQL_HANDLE_ENV, SQL_NULL_HANDLE, &henv);
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
retcode = SQLSetEnvAttr(henv, SQL_ATTR_ODBC_VERSION, (SQLPOINTER*)SQL_OV_ODBC3, 0);
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
retcode = SQLAllocHandle(SQL_HANDLE_DBC, henv, &hdbc);
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
SQLSetConnectAttr(hdbc, SQL_LOGIN_TIMEOUT, (SQLPOINTER)5, 0);
WCHAR pzSQLDriver[128];
swprintf_s(pzSQLDriver, 128,
L"Driver={SQL Server Native Client 10.0}; Server=%s; Database=master; Trusted_Connection=Yes;",
pzServerName
);
retcode = SQLDriverConnect( hdbc, desktopHandle, (SQLWCHAR*)pzSQLDriver,
wcslen(pzSQLDriver), OutConnStr, 1024, &OutConnStrLen, SQL_DRIVER_NOPROMPT );
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
retcode = SQLAllocHandle(SQL_HANDLE_STMT, hdbc, &hstmt);
WCHAR pzSQLCommand[512];
swprintf_s(pzSQLCommand, 512,
L"SELECT CASE WHEN db_id('%s') IS NOT NULL THEN 'TRUE' ELSE 'FALSE' END",
pzDatabaseName
);
pzSQLCommand[wcslen(pzSQLCommand) + 1] = L'\0';
retcode = SQLExecDirect( hstmt, (SQLWCHAR*)pzSQLCommand, SQL_NTS );
if (retcode == SQL_SUCCESS || retcode == SQL_SUCCESS_WITH_INFO) {
SQLBindCol( hstmt, 1, SQL_C_WCHAR, szDatabaseExist, sizeof(szDatabaseExist), &cbDatabaseExist );
WCHAR *szResult = new WCHAR[cbDatabaseExist];
while ((retcode = SQLFetch( hstmt )) != SQL_NO_DATA) {
swprintf_s(szResult, cbDatabaseExist, L"%s\n", szDatabaseExist );
szResult[wcslen(szResult)+1] = L'\0';
}
SQLFreeHandle(SQL_HANDLE_STMT, hstmt);
if( wcsncmp( szResult, L"TRUE", wcslen(szResult) ) > 0) {
bResult = TRUE;
}
else {
bResult = FALSE;
}
}
SQLDisconnect(hdbc);
}
SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
}
}
SQLFreeHandle(SQL_HANDLE_ENV, henv);
}
return bResult;
And then this a a preview of the contents that the thread runs for validation. If something doesn't jive, then the exitcode is generated, and returned to the thread creator, in which the thread creator generates a messagebox, and alters the dialog box.
BOOL bValidate = TRUE;
BOOL bResult = FALSE;
DWORD dwExitCode = 0;
DWORD dwWebsitePath_Check = 0;
DWORD dwProjectName = 0;
DWORD dwFolderPath = 0;
DWORD dwDomainName = 0;
DWORD dwLicenseKey = 0;
DWORD dwServerName = 0;
DWORD dwDatabaseName = 0;
DWORD dwAuthMethod = 0;
DWORD dwAccountName = 0;
DWORD dwPassword = 0;
WCHAR *szValidKey = NULL;
WCHAR *szWebsitePath_Check = NULL;
WCHAR pzProjectType[ 64 ];
WCHAR pzProjectName[ MAX_PATH ];
WCHAR pzProjectPath[ MAX_PATH ];
WCHAR pzFolderPath[ MAX_PATH ];
WCHAR pzDomainName[ 255 ];
WCHAR pzLicenseKey[ 255 ];
WCHAR pzServerName[80];
WCHAR pzDatabaseName[80];
WCHAR pzAuthMethod[80];
WCHAR pzAccountName[80];
WCHAR pzPassword[80];
PMAIN_RUNPROCESS pzValidate;
pzValidate = (PMAIN_RUNPROCESS)lpParam;
HWND cWnd = pzValidate->m_cWnd;
HWND hWndDlg = pzValidate->m_hWndDlg;
HWND lblStatusMessage = pzValidate->m_StatusMessage;
HWND pbProgressBar = pzValidate->m_ProgressBar;
PROJECT_TYPE projectType;
CA_Registry caReg;
DWORD dwProjectType = 0;
dwProjectType = ListView_GetNextItem( lv_ProjectCreate_ProjectType, -1, LVNI_FOCUSED );
if ( dwProjectType == -1 ) {
return 1;
}
else {
ListView_GetItemText( lv_ProjectCreate_ProjectType, dwProjectType, 0, pzProjectType, 60 );
if ( wcsncmp( pzProjectType, L"North American Standard Edition 2012", wcslen( L"North American Standard Edition 2012" ) ) == 0 ) {
projectType = NASE2012_STANDARD;
}
}
BOOL bDatabaseExist = FALSE;
CA_SQLServer_ODBC caODBC;
bDatabaseExist = caODBC._does_SQLServer_Database_Exist_hWnd( pzServerName, pzDatabaseName );
if ( bDatabaseExist ) {
return 13;
}
BOOL bSQLValidate = FALSE;
if ( !bSQL ) {
bSQLValidate = caODBC._validate_SQLServer_Credentials_WinAuth( pzServerName );
if ( !bSQLValidate ) {
bValidate = FALSE;
return 11;
}
}
else {
bSQLValidate = caODBC._validate_SQLServer_Credentials_SQLAuth( pzServerName, pzAccountName, pzPassword );
if ( !bSQLValidate ) {
bValidate = FALSE;
return 12;
}
}
return dwExitCode;
|
|
|
|
|
jkirkerx wrote: Access violation reading location 0x2102fe2b
What this is telling you is that you're trying to access memory that has either been deallocated already or it is stack memory that belongs to another thread. What variable is in that address? Where and how was it allocated? That should lead you to the cause of your problem.
|
|
|
|
|
I need a quick lesson on that. If I can find out what is there, I can fix my errors faster and be on my way.
|
|
|
|
|
Whenever the error comes up, you can break execution then go to the call stack and trace your path backwards to see where (within your code, not the framework) the error occurred. If you have a memory address such as this, you can look at the variables involved in the call that gave you the error and see which one has that address, that will tell you which one caused it (although it's still up to you to figure out why the error occurred).
|
|
|
|
|
I've traced my issues down to the parameters that I'm passing to the thread. I must of implemented it wrong, and left it in memory. I thought it clears automatically when the thread exits.
So this is on the CreateThread Side of the Function, and of course I read the parameters back on the Thread side.
Question:
do I have to clean up here manually, or is it automatic?
PMAIN_RUNPROCESS pzUpdateProcess;
pzUpdateProcess = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( PMAIN_RUNPROCESS ));
pzUpdateProcess->m_hWndDlg = _updates_Dialog_hWnd;
pzUpdateProcess->m_StatusMessage = lbl_Update_Dialog_StatusMessage_Label;
pzUpdateProcess->m_ProgressBar = pb_Update_Dialog_ProgressBar_Field;
hThread = (HANDLE)CreateThread(
&sa,
0,
&_updates_Dialog_CreateProcess_Thread,
pzUpdateProcess,
0,
&dwThreadID
);
The Code Analyst is complaining about a DPAC (ACL) or something below. Is it really needed for proper operation?
SECURITY_ATTRIBUTES sa;
sa.bInheritHandle = TRUE;
sa.lpSecurityDescriptor = NULL;
sa.lpSecurityDescriptor = (PSECURITY_DESCRIPTOR) malloc(SECURITY_DESCRIPTOR_MIN_LENGTH);
InitializeSecurityDescriptor(sa.lpSecurityDescriptor, SECURITY_DESCRIPTOR_REVISION);
SetSecurityDescriptorDacl(sa.lpSecurityDescriptor, TRUE, (PACL) ->NULL<-, FALSE);</b>
sa.nLength = sizeof(sa);
sa.bInheritHandle = TRUE;
sa.nLength=sizeof(SECURITY_ATTRIBUTES);
|
|
|
|
|
I didn't size it correctly, and found I had to use HeapFree to clean the memory after the thread returns.
Wow, now it works, and strange behavior went away.
PMAIN_RUNPROCESS pzValidate;
pzValidate = ( PMAIN_RUNPROCESS ) HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof( MAIN_RUNPROCESS ));
HeapFree( GetProcessHeap(), 0, pzValidate );
pzValidate = NULL;
|
|
|
|
|
By default, anything you manually create on the heap, you must manually free. Thread will only deallocate its own stack memory.
|
|
|
|
|
I'm learning Albert. It just never dawned on me that's what the holdup was on all the other problems I had with the dialog boxes, and sql server connections.
Now I can go back and use the advice and suggestions given to me over the last week.
Thanks for listening, I appreciate it.
|
|
|
|
|
Happy to help when I can... 
|
|
|
|
|
First time on this forum. Hello
I wish my first post was shorter.
And forgive the obscure title. It's hard to nail it short - I don't even know what the actual problem is.
Here's a quick description of what happens:
1) My_exe launches a 3rd_party_exe via CreateProcess(). The main process thread is in a suspended state.
2) I WriteProcessMemory() in the 3rd_party_exe process, and copy in it an absolute path, pointing to a dll I wrote.
3) I CreateRemoteThread() to have the dll loaded. It's the trite and dull LoadLibraryA() method everybody knows.
This secondary thread is created not suspended.
4) I do stuff... My_exe opens a named and synchronous pipe. My dll inside 3rd_party_exe will connect to it. My_exe writes down the pipe a path pointing to a text file. My dll inside 3rd_party_exe retrieves such path, then closes the pipe. Control is back to My_exe, which disconnects the pipe and closes the handle. No errors. Never an error.
5) My_exe now WaitForSingleObject() that the (remote) thread from point 3 gracefully comes to an end. And it always does. When that thread is done, my DllMain() has returned. I do not unload my dll from the 3rd_party_exe process. I need it to stay loaded.
6) Time to cleanup. With the remote thread closed, the memory I wrote in the process is no longer needed. So I call VirtualfreeEx() to deallocate it.
7) Only now I let the main process thread run (remember? it was kept 'suspended' since CreateProcess()).
8) I do not need to wait for 3rd_party_exe to terminate. My_exe can close. I CloseHandle() the main thread handle and the process handle (from CreateProcess()), in that order.
9) End.
What I described works -- *almost* always.
I check for errors after every API call.
When there's a problem it's VirtualFreeEx() (from point 6) reporting Access Violation (0xc0000005).
The puzzling thing is that WriteProcessMemory() is always successful. You see, I wouldn't advance all the way to VirtualFreeEx() otherwise 
Any idea what might be causing this?
I can repeat this procedure on a number of 3rd_party_exe programs. None crashes, except the one that does (lol, sorry).
I thought that perhaps this crashy program is doing something special as it starts... something that prevents me from accessing my own memory (the one from WriteProcessMemory())... but then I thought that it can't be, as the error occurs _before_ I even resume the main process thread.
How would it be interfering??
Help.
|
|
|
|
|
According to #5, you are doing all of this piping and text file retrieving inside the DllMain function?
That's a recipe for errors right there. You are never supposed to do anything but the most rudimentary initialization inside DllMain.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Thanks.
I'm unaware of specific limitations to observe or -in general- 'good conducts' to keep while inside DllMain().
I'll trust your input, and seek documentation about it later. As for the immediate...
... since the main process' thread is kept suspended and I alone decide when to let it run...
... would it be safe to CreateThread() from inside DllMain() and move all my code in there?
Or is CreateThread() another bad practice when in the context of DllMain()?
If you know better alternatives I'll listen.
Thank you again for the help.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
