|
Hi,
in the app i'm writing,i'm using ADO to connect to an Access database.I would like to pass to MySQL.How can i do this?
|
|
|
|
|
Accius wrote: How can i do this?
Use ADO to connect to MySQL instead of Access
|
|
|
|
|
Well,that's what i am doing...My question was is i can still use ADO with MySQL,instead of with Access (as i'm currently doing)
|
|
|
|
|
Moreover,i am not using the ADO.net,but the old ADO
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
