SPI_SETSNAPTODEFBUTTON in Win98 - C / C++ / MFC Discussion Boards

Prem Kumar9-Jul-02 0:08

9-Jul-02 0:08

All in all, if you do not have any experience in
Windows programming, its best that you should
start with c#.

Probably many people would not agree with me
but i think programming .Net in c# is the
fastest way to program for windows and
certainely .Net.

There is going to be ample market for .Net programmers
in c# and certainely VC++ is not going to go away
but c# will be used for a lot of UI programming.

There are a lot of books out there and also a lot of
articles on the web.

Best of luck on your .Net journey!!;)

Re: help beginner

Christian Graus9-Jul-02 0:27

Christian Graus

9-Jul-02 0:27

I disagree with the other guy. There is no reason to throw away your C++ skills to learn a lesser language, just because it is flavour of the month. MFC is pretty easy anyhow, just get a book and ask questions.

Christian

I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002

Re: help beginner

Venet9-Jul-02 0:30

Venet

9-Jul-02 0:30

I always argued that it's best to learn Win32 API first (at least basic concepts) and then move to MFC.

Regards,
Venet.

--------
Black holes are where God divided by zero.(Steven Wright)

Re: help beginner

Nish Nishant9-Jul-02 0:43

Nish Nishant

9-Jul-02 0:43

If you are good at C++ and are keen on .NET, the the best option for you is Managed C++. That way you don't have to learn a new language and you can do both .NET and native windows stuff using MC++

Good luck

Nish Smile | :)

Author of the romantic comedy

Summer Love and Some more Cricket [New Win]

Review by Shog⁹
Click here for review[NW]

Re: help beginner

9-Jul-02 0:55

Thanks for replies.
I understand that .NET is the way people will program Windows UI in the feature. I don't have any experience with c#,but heard it is very similar to Java.
I think Managed C++ is the most logical solution,to take advantages of both c++ and .NET
All these are good,but could you link me to some useful resource on all of these to start? The resources on this site are narrowed to very specific parts of MFC/ATL/.NET... etc

Re: help beginner

Dean Michaud9-Jul-02 10:08

Dean Michaud

9-Jul-02 10:08

I personally found that messing around with a few example applications from here at the Code Project (from various authors) was the best way to pick things up, really. Like you, I was doing mostly console-type apps and tons kernel mode dev., leaving my MFC and UI coding skills a little thin (actually, they were non-existent!).

Also, if you use the built-in Wizard to create an MFC app, you can get it to create a simple app for you right off the get-go that even compiles - start mucking around with the created project - I recommend starting out with a bare-bones Dialog app persobally, CDialog is a lot quicker to pick up and learn how to plop down controls and muck around with them.

Have fun with the learning, I've been messing with MFC now since Aug 2001 and have personally found that the examples here are fantastic learning tools for people who learn by example.

: Dean 'Karnatos' Michaud

Re: help beginner

Member 140239-Jul-02 21:55

Member 14023

9-Jul-02 21:55

Thank you,That is exactly what I need Smile | :)

Vitaliy

SPI_SETSNAPTODEFBUTTON in Win98

Alek8-Jul-02 23:38

Alek

8-Jul-02 23:38

SystemParametersInfo(SPI_SETSNAPTODEFBUTTON, true, NULL, SPIF_UPDATEINIFILE | SPIF_SENDCHANG)
Above is my code.
It works in WinMe, Win2000 and WinXP
but does not work in Win98.
Is anyone can give me any suggestion?
Thanks a lot.

Linker error: LNK2001 with GetModuleBaseName and EnumProcessModule

Janine8-Jul-02 23:31

Janine

8-Jul-02 23:31

Hello,

I'm trying to use GetModuleBaseName and EnumProcessModules, but I'm doing something wrong because I get linker error 2001. I guess that the problem is with WINAPI.

I have a .c file that is forced to be compiled as c++ and I call those functions from there like this:
EnumProcessModules(hProc, &hMod, sizeof(hMod), &cbNeeded);
GetModuleBaseName(hProc, hMod, pParentName, sizeof(pParentName));

Then I'm using PSAPI.h where I have

-- clip --
#ifdef __cplusplus
extern "C" {
#endif
-- clip --
BOOL
WINAPI
EnumProcesses(
DWORD * lpidProcess,
DWORD cb,
DWORD * cbNeeded
);
-- clip --
DWORD
WINAPI
GetModuleBaseNameA(
HANDLE hProcess,
HMODULE hModule,
LPSTR lpBaseName,
DWORD nSize
);

DWORD
WINAPI
GetModuleBaseNameW(
HANDLE hProcess,
HMODULE hModule,
LPWSTR lpBaseName,
DWORD nSize
);

#ifdef UNICODE
#define GetModuleBaseName GetModuleBaseNameW
#else
#define GetModuleBaseName GetModuleBaseNameA
#endif // !UNICODE
-- clip --
#ifdef __cplusplus
}
#endif
-- clip --

Now I get:
myprogram.obj : error LNK2001: unresolved external symbol _GetModuleBaseNameA@16
myprogram.obj : error LNK2001: unresolved external symbol _EnumProcessModules@16

Why? Confused | :confused:

I've read many examples and it seems to me that I'm doing this in the same way as they do.

I would be glad if someone helped me with this. Smile | :)

-Janetta

Re: Linker error: LNK2001 with GetModuleBaseName and EnumProcessModule

Prem Kumar9-Jul-02 0:11

Prem Kumar

9-Jul-02 0:11

Ok, it is a linker error !
Come on, its the most common of the
linker errors !.

You forgot to include the psapi.lib
in your linker tab.

Re: Linker error: LNK2001 with GetModuleBaseName and EnumProcessModule

Janine9-Jul-02 0:47

Janine

9-Jul-02 0:47

It is very common, but there are many reasons why you get it. Maybe this mistake was trivial, but it was new to me. Thank you anyway Smile | :)

-Janetta

Invoking an executable program from a remote machine

8-Jul-02 23:22

Hi all,
I'm working with a database application in which the data base is located in a remote machine(Machine 1).The application which makes use of that data base is running on a remote machine(Machine 2).Both computers are running under Windows 2000 and are connected in LAN.I would like to clear my database(The database located in machine 1) once in a month by running an exe in that machine.How can i invoke another executable program(program for backing up the data base) which is located in machine 2 when the data base clearing program in machine 1 is just started.Can any one help me?.
With regards.

Shibu K.V.
Senior Research Associate.
VLSI ASIC Hardware Design Group
Electronics R&D Centre,Trivandrum
India

Re: Invoking an executable program from a remote machine

Prem Kumar9-Jul-02 0:16

Prem Kumar

9-Jul-02 0:16

There is no existing infrastructure in place currently
to invoke a program at the remote machine.

Wait there is one way, Use the Task Schedular API.
But make sure that the remote exe is scheduled to
a future time and that it does not have a UI.

Or you could always use a Service and keep
listening on a specified port.

Re: Invoking an executable program from a remote machine

Ollie9-Jul-02 0:37

Ollie

9-Jul-02 0:37

Most database applications have ablility to schedule tasks and jobs, so why write an application to do it?

Re: Invoking an executable program from a remote machine

Renjith Ramachandran9-Jul-02 0:54

Renjith Ramachandran

9-Jul-02 0:54

use the Sheduletask API
or write a service

Renjith-CPian.

CreateFile problem

Senkwe Chanda8-Jul-02 23:04

Senkwe Chanda

8-Jul-02 23:04

Ok, this is a revisit to the problem that Chris Losinger tried to help me with. I had wrongly thought GetFileSize was the problem, he helped me determine that was not the case, thanks again Chris!!

I have an app associated with a certain file type. When I double click the file, it opens up my app. In this way the file name is passed to the app. This works fine and I have proved it by popping a message box with the filename on it. As you can see below m_EncryptedFilePath is the file name in question.

HANDLE hOriginal = ::CreateFile(m_EncryptedFilePath,           
               GENERIC_READ,              
               FILE_SHARE_READ,           
               NULL,                      
               OPEN_EXISTING,             
               FILE_ATTRIBUTE_NORMAL,     			   
               NULL);

Now, in DEBUG mode, all is dandy. hOriginal is not NULL. But in RELEASE mode, it is NULL even though the correct file name is passed through in each case.

Could it be file permissions?? Access rights?? The way I'm associating the file with the app??

By the way, release mode works fine if I hard code the file name like so

HANDLE hOriginal = ::CreateFile("c:\\myfile.abc",           
               GENERIC_READ,              
               FILE_SHARE_READ,           
               NULL,                      
               OPEN_EXISTING,             
               FILE_ATTRIBUTE_NORMAL,     			   
               NULL);

So I'm completely at my wits end over this at the moment. Any and all comments will be appreciated.

Senwe

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Re: CreateFile problem

KarstenK8-Jul-02 23:12

KarstenK

8-Jul-02 23:12

What does GetLastError() return?

Re: CreateFile problem

Senkwe Chanda8-Jul-02 23:15

Senkwe Chanda

8-Jul-02 23:15

Good question, in DEBUG mode it returns 0, implying all is well. That's why when I'm debugging everything works. The release version of CreateFile returns a NULL handle.

Perhaps I should place a FormatMessage and populate a MessageBox to retrieve GetLastError in my release mode?

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Re: CreateFile problem

KarstenK8-Jul-02 23:34

KarstenK

8-Jul-02 23:34

If you think, that to populate a MessageBox is the right answer, you have to do it. (If you know what I mean)

I also have these type of problems and I have to fix them. The first step is to get a "handle" to the problem.

You have there a member variable for the file name. I guess it is a CString -> (LPCSTR) cast is best practise.

Try also Release Output of it to check its ok. ( I Do a Findfile to check this). Unsure | :~

Re: CreateFile problem

Senkwe Chanda8-Jul-02 23:38

Senkwe Chanda

8-Jul-02 23:38

KarstenK wrote:
The first step is to get a "handle" to the problem.

Yep and my assumption was correct, the file isn't being recognised. GetLastError confirms this.

KarstenK wrote:
I guess it is a CString -> (LPCSTR) cast is best practise

Well yes, a WTL CString, not an MFC CString Smile | :)

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Re: CreateFile problem

Senkwe Chanda8-Jul-02 23:23

Senkwe Chanda

8-Jul-02 23:23

GetLastError returns the following...

The filename, directoryname, or volume label syntax is incorrect

Which is what I assumed...but I just don't see how or why.

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Re: CreateFile problem

Ollie8-Jul-02 23:29

Ollie

8-Jul-02 23:29

Hi,

Sounds like a memory allocation\deallocation problem with 'm_EncryptedFilePath' especially if the path is correct('\\' etc) and it works when you hard code the path.

What type of string is 'm_EncryptedFilePath'?

Re: CreateFile problem

Senkwe Chanda8-Jul-02 23:31

Senkwe Chanda

8-Jul-02 23:31

Hi Ollie, it's a WTL CString. I've always used it as a drop in replacement for MFC's CString in most cases.

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Re: CreateFile problem

Ollie9-Jul-02 0:01

Ollie

9-Jul-02 0:01

have you tried making a local copy of the string and then using it, sorry not up to speed on WTL CString, what is the underlying type?

Re: CreateFile problem

Senkwe Chanda9-Jul-02 0:06

Senkwe Chanda

9-Jul-02 0:06

No prob Ollie, it's a great library as you already know I'm sure, please do explore it for your new win32 work Smile | :)

The underlying type is LPTSTR. I think you're onto something though. Let me explore the CString header file more carefully.

And when God, who created the entire universe with all of its glories, decides to deliver a message to humanity, He WILL NOT use, as His messenger, a person on cable TV with a bad hairstyle.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.