|
|
I have a static control with horizontal and vertical scrollbars.
Both scrollbars are enabled and effective (i.e. there is scrolling amount), working fine.
The static control is a subclass of CStatic. I am monitoring the mouse actions in this static control with OnLButtonUp, OnLButtonDown, OnRButtonUp, OnRbuttonDown and OnMouseMove.
Additionally, there is an OnMouseMove in the parent window of the static control (which is the dialog). This monitors if the mouse leaves the rectangle of the static control.
Everything works fine, EXCEPT when the mouse moves from the static control over the vertical scroll bar rectangle, this will not be reported to the parent's OnMouseMove
However, there is no problem with the horizontal scroll bar, and if the vertical scrollbar is disabled, then the mouse move will be reported.
What can be the reason to this behaviour?
|
|
|
|
|
That sounds strange.
If the scrollbars are standard scrollbars (not controls) then they are part of the non-client
area of the static control. I would expect the wParam of a WM_NCMOUSEMOVE message in the static
control then would be HTHSCROLL/HTVSCROLL.
*edit* I guess I should clarify - what sounds strange to me is that the parent would get a
mousemove message when the cursor is on the scrollbar of a child window...
-- modified at 16:15 Thursday 14th June, 2007
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The scroll bars are separate controls. I'm sorry, I did not mention this, because I thought the fact that the mouse movement over the horizontal scroll bar will be reported makes this clear.
|
|
|
|
|
In that case, it still sounds strange.
I would expect the mousemove messages to go to the scrollbar controls, not the parent 
Are the scrollbars children of the dialog or the static control?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
The scrollbars are children of the dialog.
|
|
|
|
|
I can't see where the behavior would be different between the scroll bars.
WM_MOUSEMOVE messages go to the window under the cursor. If the cursor is over a scrollbar
control then the messages should go to that control.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
We have a COM dll built on windows 32 bit OS.
When this dll is attempted to be registered on a 64 bit platform,we get the following error:
INFO: Calling Action w32OcxRegActions10.2.0.1.0 RegisterOCX
OcxPath = ..........dll
WorkingDir = ...........\bin
INFO: Exception thrown from action: RegisterOCX
Exception Name: ErrorRegisteringOCXException
Exception String: OLE initialization or OCX load error while registering OCX
Exception Severity: 0
This dll is registered successfully on a 32 bit platform.
Does not a dll built on 32-bit XP(win2k) get registered on a 64-bit XP using regsvr32?
|
|
|
|
|
I have a DLL which has options to do different tasks based on the options selected during initialization
lets call this A.dll
so say there is an intialization API
AInit( int mode = mode2) // can take mode1 or mode2
Now applications App 1 and App 2 can load this dll but load using different options.
I want to prevent this from happenning simultaneously. in other words my requirements is that someone loads A in mode 1 or mode 2 but not simulataneously in mode 1 and mode 2.
Additionally i could have multiple users, load A.dll in mode 2 ( multiple readers ) but
multiple of Mode 1 or a mix of Mode 1 and Mode 2 should be disallowed.
Is there a way I enforce this in code or ideas to do the same ?
I was thinking on the lines of a Mutex !
Engineering is the effort !
|
|
|
|
|
A Mutex is exactly what you need. Specifically a named Mutex which by being named can therefore be shared between Processes.
Nothing is exactly what it seems but everything with seems can be unpicked.
|
|
|
|
|
Hello everyone. I currently have a combination program that is spitting out millions of combinations into a single .txt file and i am having issues with the file crashing when it tries to open. I was wondering if there is a way you can set up the program to put like 500k combinations in one file and then create another file untill it runs out of combinations. I am fairly new to C++ and any help would be appricated. I will post my current code later when i get back home from work. Thank you!
|
|
|
|
|
It seems simple matter... But if you post the relevant code maybe even simpler
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
ciphus21 wrote: ...i am having issues with the file crashing when it tries to open.
I'd be more concerned with this at the moment. Splitting the file, even if it worked, sounds too much like "patch."
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
ciphus21 wrote: having issues with the file crashing when it tries to open.
I guess that means your app. is crashing when it opens the file? This "Splitting" you talk about won't fix your error. Even if you are running out of memory splitting the file is not a good solution but paging the file into memory would be.
|
|
|
|
|
Do people ever do this:
{
int i, j, k, l, m, n, o;
for (i = 0; i < 1000; i++)
{
}
}
This would be a way to clear i->o off the stack as soon as you don't need them anymore, right? My main reason for using this would be, if I had many variables, and I didn't want to accidentally redefine any variables throughout the entirety of the function. Then again, I could also split it up into multiple functions.
|
|
|
|
|
I only do that in cases where I use a scarce resource like a device context. When you have just ints, those use a relatively insignificant amount of stack space. If you're running into naming errors, fixing the code is preferable to sticking scopes in.
|
|
|
|
|
Michael Dunn wrote: I only do that in cases where I use a scarce resource
Heck, you were typing faster 
|
|
|
|
|
Well, the problem I'm dealing with is that before I make a function call to say, AddWorkToWorkQueue(), I have to initialize a bunch of pointer variables just to set up this call (which this call will use). AddWorkToWorkQueue, however, is a very dynamic process, and I expect to be able to call it anywhere as much as I want.
Because of this, I do not want to explicitly make this repetitive call in my code -- instead, I define a macro for it, which contains several lines of code. The thing with a macro, is that once you define it, you define it. The variable names you define in a macro do not change, so if you use this macro multiple times, you will get variable redefinitions.
I also want to make this macro easy to use, which means that I don't want the user to be forced to keep track of how many times he has used this macro and pass in an additional number as a token parameter to be concatenated at the end of every variable name (see ## - token pasting preprocessor).
The solution I therefore use, is to enclose my macro with {}, allowing me to initialize all the variables I want without any redefinition.
Note: I did mention in the beginning that I was initializing a bunch of pointer variables. We all know what happens when you go out of scope on pointer variables that have not been deleted -- you get a memory leak. No worries -- I also delete the pointers asynchronously by keeping track of them in an STL container.
|
|
|
|
|
You said that you are using an STL container to keep track of pointers. Since you are using C++, you really should consider changing from using macros to instead use inline routines. Except for certain special diagnostic or logging routines (where you want to access preprocessor macros such as __FILE__ or __LINE__), there normally isn't any need to use macros in C++ for blocks of code.
In this case, it sounds like you should just make a small inline routine which declares and initializes the variables needed to call your other routine. This small routine can then be used as many times as you want, as the scope of the variables are within the routine. By making it inline, there should be no additional overhead beyond what you would get from a macro. You also won't need to pass in a number as a token parameter, as you won't get variable redefinitions if you use an inline routine instead of a macro.
As far as keep tracking of pointers to delete, I would suggest that you instead use an appropriate smart pointer, using the lightest weight smart pointer that you can. For many simple cases, an std::auto_ptr is sufficient or even a boost::scoped_ptr will work. For more complicated cases, a reference counting smart pointer such as boost::shared_ptr might be needed. Without knowing how you are using the pointers, I couldn't tell which would be a better choice.
|
|
|
|
|
Well, the reason why I use a pointer instead of a smart pointer that exits once it goes out of scope is because I need to make sure that my pointers exist until I actually use them, which may be a while after I initialize them. As such, if I were to use a local variable (which I could very well do) and they were to go out of scope before I use them, then by the time I actually use them (my pointers encapsulate function pointers), I would be getting serious errors. To me, the concept of a smart pointer is the same as the concept of a local variable (in this case). They both do graceful shutdown when they go out of scope, which is exactly what I don't want.
I'm not sure about using inline functions as I've never used them before, but I will look into it. I thought it was more of a performance optimization than a functional technique (as in -- it works the same way as any other function except that for functions that get called really often, it will increase performance).
|
|
|
|
|
The main point I was trying to get across was that you should avoid using macros in C++ except in a very small number of special cases. Using macros is generally the C method of doing things, not the C++ method.
Whether you make the routine that replaces the macro into an inline routine or just a callable routine is not important. I only suggested an inline routine since it produces almost exactly the same result as a macro - no additional function call being made in the generated code. You would get the same benefits with a normal routine instead of an inline routine except the generated code would probably include a call to this normal routine. Note: some compilers may choose to inline a small normal routine without you adding the inline keyword. Also, some routines marked as inline might still result in a function call - the compiler doesn't have to inline a routine when you tell it to inline. This generally doesn't happen, but there are a few cases where it is needed (such as if you get a pointer to the inline routine and then call it through the pointer).
The usage of smart pointers may or may not be appropriate in your case. It just tends to make the cleanup code a lot easier. As long as you can arrange to have the scope of the variable end when you no longer need the resource, then you don't need to do any explicit calls to delete the object. Sometimes it just takes a little reorganization to take advantage of smart pointers. Without seeing your code, I can't tell whether you could use smart pointers by just rearranging things a bit.
You said that you were placing the pointers into an STL collection for future cleanup. You could place a boost::shared_ptr into the collection, which would simplify the eventual cleanup. Instead of needing to loop through the collection and manually deleting each pointer, you can just clear the collection. The boost::shared_ptr would then take care of cleanup automatically.
|
|
|
|
|
Modified: The following is my defined macro (without the line breaks for readability) -- given that I'm passing in types and function pointers, the syntax can get quite hairy. Do you think using an inline function would actually work in this case?
#define PROCESS(type, function, args)
{
CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(##type&), ##type>* cbwSpecific =
new CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(##type&), ##type>
(this, &MainWindow::##function, ##args);
CallbackWrapperGeneric<##type>* cbwGeneric = cbwSpecific;
CallbackWrapperDestroy* cbwDest = cbwSpecific;
CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_##function, cbwDest);
m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));
}
As for the boost library, I will try what you've suggested.
Thanks.
|
|
|
|
|
I didn't read your reply until this morning, so I am just replying now.
Looking at your PROCESS macro, it seems like most of it could easily be changed to be a member template function of class MainWindow (although I am making some assumptions about what the various symbols are).
The assumptions that I am making are:
- CallbackWrapperSpecific is a templated class derived from CallbackWrapperGeneric.
- The args passes to PROCESS is a specific variable with the type matching the first argument passed to PROCESS.
- The PROCESS macro is being used inside a member of MainWindow. I assume this because the "this" pointer is being passed to the constructor of CallbackWrapperSpecific.
- The m_localWorkMap is a member of MainWindow which is used to hold thread ids which map to CoreWorkUnit * objects (part of your cleanup mechanism).
- The m_threadPool is a member of MainWindow which is used to create a thread to process the request, with its Process member returning the thread id.
Given these assumptions, the only problem line that I see in the entire macro is:
CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_##function, cbwDest);
This line is constructing a Function_ name from a combination of a constant string and the name of the member routine in MainWindow. This appears to be the only line which can't directly be converted into using a member template function. If you could explain what this is for, perhaps I could suggest another way to do this.
The rest of the code looks straight forward and should be easy to change - the following is close to what would be used (if my assumptions were correct):
<br />
template <typename type><br />
void Process( void (MainWindow::*memberFn)(type&), type args )<br />
{<br />
CallbackWrapperSpecific< MainWindow, void (MainWindow::*)(type&), type >* cbwSpecific =<br />
new CallbackWrapperSpecific< MainWindow,void(MainWindow::*)(type&), type>( this, memberFn, args );<br />
<br />
CallbackWrapperGeneric<type>* cbwGeneric = cbwSpecific;<br />
CallbackWrapperDestroy* cbwDest = cbwSpecific;<br />
CoreWorkUnit* cWorkUnit = new CoreWorkUnit( cbwDest);<br />
m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));<br />
}<br />
Note that I commented out the first argument to the CoreWorkUnit constructor as I didn't know what to put here.
The calling sequence is slightly different, as you pass the type as a template parameter, and the address of the MainWindow routine as the first argument - the call would look something like:
<br />
Process<int>( &MainWindow::DoSomething, 1 );<br />
|
|
|
|
|
I am surprised that you were able to deduce so much from just seeing this code snippet -- your assumptions are almost 100% on the spot. The m_localWorkMap actually holds work IDs and the call to Process from m_threadPool returns the work ID so I can insert it into m_localWorkMap. In my ThreadPool class (not shown), I have a work ID being mapped to a WorkUnit. In my local (caller) class, CoreWorkUnit maps work IDs to resources that I need to free (namely cbwDest, as you can see above, which is the basest class of CallbackWrapperGeneric and CallbackWrapperSpecific) and the function name. Say I pass in MyFunction as my "function name", when the CoreWorkUnit constructor executes, it will set an enum value for CoreWorkUnit (Function_MyFunction). This is used when I get my data later on (I have to know which work ID corresponds to which work function that I actually called). I can easily fill this in by just passing the enum value directly (but one of my goals is to make PROCESS simple and as parameterless as possible to use, so I'll take that into account.
The below seems to work...
template<class T>
inline void MainWindow::Process(void (MainWindow::*funcPtr)(T&), T args)
{
CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(T&), T>* cbwSpecific =
new CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(T&), T>(this, funcPtr, args);
CallbackWrapperGeneric<T>* cbwGeneric = cbwSpecific;
CallbackWrapperDestroy* cbwDest = cbwSpecific;
CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_DoWork, cbwDest);
m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));
}
...with the following prototype...
template <class T> void Process(void (MainWindow::*funcPtr)(T&), T args);
To be honest, I didn't think a class member template function was possible without the class being a template class, so now I have dispelled another myth.
-- modified at 10:10 Friday 15th June, 2007
|
|
|
|
|
That makes sense in some situations when you want a resource to be held as short as possible. Ie:
{
mutex lock(some_lock);
...
}
But as you said it is often better to have it as a separate function.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
