C / C++ / MFC

Microsoft Access Database Import to VC++ Windows Forms

17-Aug-06 4:58

Hi,

Can a namespace extension be installed on a limited users account? To install one only accesses the HKEY_CURRENT_USER part of the registry (as far as I remember) so does this mean that they can be installed?

Thanks in advance

Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com

Nokoff17-Aug-06 4:56

Nokoff

17-Aug-06 4:56

Hi there guys, I am currently trying to achieve a seemingly simple task in VC++ 2005. I have made a very simple form in Microsoft Access which I wish to serve as the beginnings of something greater. I created a db in MS Access named links.mdb containing on table-> Table1. Table1 contains 1 column, "Links", and i wish to read these strings into variables in my Visual C++ Windows Forms Application.

What I have done so far...

In Visual C++, I clicked on Data->Add new data source, and followed the wizard to add the microsoft access database to my application by the name, "linksDataSet". I can see the table in my left hand "Data Sources" pane in VC++. All I need to know is how to access my database from here so that I can read these strings stored in my table. Also, would be possible to schedule my application to log on to a http server and retrieve these links every time the application is executed? How would I go about doing this?

Thank you very much for your time
Regards
Linden.

Re: Microsoft Access Database Import to VC++ Windows Forms

cje17-Aug-06 5:15

cje

17-Aug-06 5:15

the sounds like you are using managed code - are you posting in the correct forum or are really using VC++/MFC?

cje

Windows Directory

si_6917-Aug-06 4:49

si_69

17-Aug-06 4:49

Hi
Can anyone tell me the best way to obtain the windows directory and drive

thanks

Simon

Dave Kerr17-Aug-06 4:56

17-Aug-06 4:56

Look up SHGetFolderPath in the documentation and use the flag 'CSIDL_WINDOWS', this will get you the path to the windows folder (typically c:\windows).

Always use SHGetFolderPath for special folders like My Documents, Program Files and so on. It's a bit of an ugly function so I'd wrap it in something a bit cleaner that returns a string.

Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com

Michael Dunn17-Aug-06 13:23

Michael Dunn

17-Aug-06 13:23

CSIDL_WINDOWS was only recently added to the CSIDL_* list. Use GetWindowsDirectory() to have your code work on all versions of the OS

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

Hamid_RT17-Aug-06 6:32

Hamid_RT

17-Aug-06 6:32

See GetWindowsDirectory

WhiteSky

Using Spy++ in Visual Studio 2003

G_S17-Aug-06 13:29

G_S

17-Aug-06 13:29

UINT GetWindowsDirectory(
LPTSTR lpBuffer, // buffer for Windows directory
UINT uSize // size of directory buffer
);

G_S

Jethro6317-Aug-06 4:40

17-Aug-06 4:40

Hi:

Does anybody know of a good tutorial or getting started resource for using the "Spy++" tool that comes with Visual Studio?

I have a problem with a MFC application which I suspect may be traced if I can look at the Windows messages being shot through my application. However, every time I fire up Spy++, I end up throwing up my hands in dispare.

Specifically, I would like to know how to identify which window I should be watching from the enormous list of windows that are listed in the "Windows" window. Its not obvious and I often find that the name of my application appears embedded in three or more of the entries in the listing. Then, I would like to know how to isolate messages that are being directed to specific windows and possibly even narrow this to specific controls.

Do people find "Spy++" useful? Or are there better ways to debug problems?

Thank you,
Mark

G_S17-Aug-06 4:53

G_S

17-Aug-06 4:53

Spy++ is a great tool

First of all start the application directly meaning not executing it through VC++.
Second a better approach is to list processes it is simply easier to find your exes name then open up the tree you'll see all the threads if mulitple scan the threads for the window/control your looking for
right click the window/control you want and click messages you'll see messages that window/control receives to isolate messages click on logging options on the toolbar or just click CTL+O
there you have what kind of message tracing you want.

G_S

Jethro6317-Aug-06 7:35

17-Aug-06 7:35

Thanks G_S. I did try starting my program away from the IDE and it certainly was easier to isolate my application and also its sub-controls and lok at only the messages I was interested in.

Alas, I still have not figured out what keeps repainting my custom control...

Cheers,
Mark

Dave Kerr17-Aug-06 4:53

17-Aug-06 4:53

Hi Mark,

By far the best way to debug (although this depends on preference and opinion) is to just the visual studio debugger, and step through code that you need to test line by line.

Get familiar with breakpoints and 'step in/step out' for functions. The debugger is powerful enough for you to walk through code as it is executing, line by line, make changes on the fly and compile them back into the running program. If you notice a line of code didn't work the correct way, you can change the line, compile the changes, tell the debugger to step back to that line and execute it again. You can keep on doing this until you've got the code correct.

This line by line debugging will also greatly ease your use of spy- because when you step over a line of code you'll probably only end up sending one windows message (or none at all), and you won't get the floods of mouse messages.

Try using Winspector Spy (a free tool on the net), it corrects some of the most common quibbles with spy++. In terms of using spy itself, the most useful feature is under 'Search>Find Window'. You can drag the Finder tool over the window you want to spy on and it selects it for you automatically; very useful if you need to find a window such as a statusbar which may not have a caption.

When watching windows, go to the 'logging options' and make sure you're not logging mouse messages, paint or nc (non-client) paint messages, otherwise you tend to get a continuous flood of nonsense.

So whilst watching a window you are debugging step-by-step, you can generally see what's going on. The only limitation of the step-by-step debugging is that it doesn't do windows messages well, because they go through a message pump etc which makes stepping in and out of those functions very complicated. For checking dodgy code though, the debugger should be your first check, get comfortable with it, it's an extremely powerful tool.

Hope this helps Mark

Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com

Jethro6317-Aug-06 5:10

17-Aug-06 5:10

Hi Dave:

Thanks for your response. I guess I should have been a little more specific about the kind of problem that I am having. I've been using Visual Studio for years and, yes, the line-by-line debugger, stepping in, stepping over, breakpoints and the various watch windows is always my first recourse when debugging and testing.

My problem is that I suspect that there are windows messages being issued that I am unaware of and might be working against me. Sounds like conspiracy theory, I know, but the Reader's Digest version of my problem is that I am trying to customize a control. It is user drawn. In "DrawItem", I am painting the control's background a certain colour, when I step through and view this procedure, I can see that the "DrawItem" procedure is indeed painting the background. But as soon as I allow the program to continue, some other entity is un-painting my background. I assume that this is a Windows message that I had not anticipated. This is why I would like to see what messages are being issued.

Am I correct in assuming that it is the WM_PAINT message that is eventually calling the "DrawItem" procedure? Or have I misunderstood?

Anyway, that is my story. I do not know if Spy++ would help me here or not but I have been spinning my wheels here since late last night and I am willing to try anything at this point.

Thanks,
Mark

Dave Kerr17-Aug-06 7:23

17-Aug-06 7:23

Hi Mark,

OK- I thought it was a much more general question, I didn't mean to sound patronising to someone who's been using studio for years!

First things first- make sure you are handling the WM_ERASEBKGRND message and returning FALSE- otherwise during the drawing sequence the system will try and erase the control's background. This sounds like the most likely problem.

If it's more complicated custom drawing you're doing, such as list items in list controls, then look in the documentation for how to set the background. For example as far as I can remmeber with things like tree controls, to customise the tree items background, you handle the custom draw notification, but don't erase the background, you set the background colour in the passed device context to what you want, and then the system erases it for you.

So if the background is being unpainted, check for the WM_ERASEBKGRND message and make sure you handle it, and for tree/list/more complicated controls, make sure that to change the background you're setting the correct variable in the device context.

If none of this works and spy doesn't pick up any cheeky little messages being boosted around without your knowledge, then it might be worth posting the explicit problem somewhere and seeing if it's been encountered before...

Good luck,

dave

Dave Kerr
codechamber@hotmail.com
http://www.codechamber.com

Jethro6317-Aug-06 7:33