|
Thank you for the reply.
I had thought of that, but again I did not want to compromise the throughput speed that the application currently delivers.
But, I have been thinking about this all night and I cannot think of another solution that would 'scale' as well as your suggestion.
So, it looks like thats the road I will have to take.
Best regards.
And again, thank you for the reply.
James.
|
|
|
|
|
After much deliberation and study of my code, I have decided to abandon the idea of trying to handle more than 64 events.
It is just not possible to integrate multiple threads, each waiting on a set of 64 events.
I need to be able to maintain the current application throughput and the overhead would be too much.
The list of events that I wait on is not constant and is waited on upto 3000 times per second.
The intended user will just have to deal with the limitation.
So thats that.
|
|
|
|
|
Hi,
I have a question if there is a limitation on the number of timers that could run on a Dialog.
SetTimer method of the CWnd class is used.
|
|
|
|
|
Hi,
AFAIK (As Far As I Know) there is only a limitation within Windoze, they say there is a maximum of timer handles Windoze can handle (how poetic), but I've never heard of a limit within a dialog..?
hope it helps...
---
YOU KNOW WHAT YOU ARE BLONDIE!?!? YOU'RE JUST A SON OF A BA A A A AAAAAAAAAA!!!!!
http://sprdsoft.cmar-net.org
http://t1tan.cjb.net
|
|
|
|
|
ok let me reframe the question to how many timer handles Windoze can handle given the fact that all the "OnTimer" processing happens on a single UI thread
|
|
|
|
|
|
I see the following behavior under VC6:
template <class T> void foo()
{
printf("sizeof(..)=%i\n", sizeof(T));
}
int main(int argc, char * argv[])
{
foo<BYTE>();
foo<float>();
return 0;
}
(the real implementation is a bit more complex, it's a bit more complex, seems like at (*) VC6 chooses to call the float variant)
However, when I change the function declaration to
template <class T> void foo(T * p = NULL)
{
printf("sizeof(..)=%i\n", sizeof(T));
}
it seems to work correctly.
I know that you can't templatize functions by values, only by types - btu that the types must appear in the argument list??!!
Is this (yet another template-related) bug of VC6, or is this what the C++ Standard says?
(I'm pretty much pissed anyway, checking a few dozen templates if they need the T*=NULL trick, but I'd like to know at least if it's my ignorance or the compiler's fault)
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist || Agile Programming | doxygen
|
|
|
|
|
must be a VC6 bug. the same code in VC7 gives the correct result.
Software | Cleek
|
|
|
|
|
Yes, VC 6 has problems when a type template parameter doesn't appear in the function's parameter list. Your dummy T* p = NULL parameter is the normal workaround.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
"That probably would've sounded more commanding if I wasn't wearing my yummy sushi pajamas."
-- Buffy
|
|
|
|
|
|
I have been having problems trying to set up a plugin for my program. The program loads a DLL dynamically, and then calls a member function:
__declspec(dllexport) int Start(CDervDlg *dlg)
{
dlg->m_SomeVar = TRUE;
dlg->SomeFunc("Blah", "Blah");
}
I've tried using both regular DLLs and Extension DLLs, but neither work.
This is probably just something obvious that I just can't see, but can anyone help?
|
|
|
|
|
if SomeFunc is on the DLL, you have to dllexport it when generating the DLL and dllimport when generating the EXE.
If it is an MFC extension DLL, you can use the AFX_EXT_CLASS macro, for example:
class AFX_EXT_CLASS CMyDlg : public CDialog
{
};
Jaime
|
|
|
|
|
Somefunc is in the EXE.
class CDervDlg : public CDialog
{
void TestLoad();
void SomeFunc(CString, CString);
BOOL m_SomeVar;
};
typedef int (*SCGptr)(CDervDlg *);
void TestLoad()
{
HINSTANCE inst = AfxLoadLibrary("testlib.dll");
SCGptr Startfunc = (SCGptr)GetProcAddress(inst, "?Start@@YAHPAVCDervDlg@@@Z");
if (Startfunc != NULL)
Startfunc(this);
}
#include "DervDlg.h"
__declspec(dllexport) int Start(CDervDlg *dlg)
{
dlg->m_SomeVar = TRUE;
dlg->SomeFunc("Blah", "Blah");
}
Thank you for helping.
|
|
|
|
|
In DLL you have to declare:
class __declspect(dllimport) CDervDlg : public CDialog
{
void TestLoad();
void SomeFunc(CString, CString);
BOOL m_SomeVar;
};
and in EXE:
class __declspect(dllexport) CDervDlg : public CDialog
{
void TestLoad();
void SomeFunc(CString, CString);
BOOL m_SomeVar;
};
In your DLL you are using a function declared in the EXE, that's why you need to export from the EXE, and import it into the DLL.
Jaime
|
|
|
|
|
Thank you very much. It works now.
|
|
|
|
|
Hello,
In terms of performance, good programming, etc, is it better to derive [customized] classes from CDatabase and CRecordSet or is it preferable to build our own from scratch? What do you think about this?
What I am trying to know is whether a Database Programmer finds all the functionalities he/she needs in these MFC classes or whether they'd be better off creating their own from scratch.
All insights on the subject are very much appreciated.
Thank you,
David
|
|
|
|
|
AFAIK CDatabase, CRectordset, etc, connects to a database by using ODBC driver, and that way of connection is always slower than accessing directly database native driver, as it adds other layer to the database connection. They are easy to use, bad provide poor performance.
To connect to database I programmed my own class named CDatabase that encapsulates all database connection using ADO.
It's known that by using ADO, the program doesn't access directly the database driver, but it's only one layer over the OLEDB driver, being a good choice (and easy choice) to access a database.
Jaime
|
|
|
|
|
But what kind of database(s) do you usually use? MsAccess and the likes, or Oracle/... ?
I am asking this because I heard something before about the ADO technology only allowing you to connect to the Microsoft Jet -type databases. Is this right?
dNimrod#X
________________________
|
|
|
|
|
it's wrong. ADO can connect to any database that has supporting driver installed in the system. I have used it in Access (Microsoft Jet), SQL Server (SQLOLEDB) and Oracle (MSDAORA)
Jaime
|
|
|
|
|
I see! I hope you'll bear with me, I am a newbee in database programming...
Let me ask you though, is there any MFC class supporting ADODB connections?, I've been searching but found none...
For what I could see, ADODB connections are a form of interacting with databases through OLE ?
|
|
|
|
|
MFC doesn't provide a class for connecting to database using ADODB, that's why I programmed my own CDatabase class that #imports the ADO DLL to use the wrapper classes, and call the more common methods, for example, Execute to execute a query.
In order to fully understand, you need knowledge on COM technology.
I think here in codeproject you may be able to find info on this topic (in www.google.cl you can find a lot of stuff, for sure)
Jaime
|
|
|
|
|
Thanks a lot for all the input, Eduardo!
Cheers,
David
|
|
|
|
|
you are welcome... but my name isn't Eduardo, it is Jaime, and my surname Stuardo
|
|
|
|
|
I am sorry for having mixed up your name, Jaime!
Again, thanks for the help!
David
|
|
|
|
|
I haven't used the MFC database classes for quiet a few years. I much prefer to use ADO.
There are some nice wrapper classes here[^]
Michael
CP Blog [^]
|
|
|
|