|
ivax wrote:
I need to retieve the informations of users of a Windows Server in order to my application.
I don't quite understand your question, but perhaps I can speculate and offer these:
NetUserEnum()
NetUserGetGroups()
NetUserGetLocalGroups()
NetUserGetInfo()
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Thanks David.
Mu propose is retrieve UserId, Name and Password, Insert them in my Table. When a User Login in a Server I want to use the User Id And PWD in order to login in my app.
For example: A user is logged in a the Windows Server like UserId = IVAX and PWD = MYPwd.
If this User want to login in my app then he must enter again one valid UserId and PWD defined in my Database (MS-ACCESS).
My porpouse is use the User information from Windows Server Database in My application adding in my Table Users other information more.
Thanks again
Xavier
|
|
|
|
|
To my knowledge, there is no way to obtain the password that was used to login to the machine (that's not to say that a way does not exist). The user id is easily obtainable.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
You can't user's passwords at all. See Raymond Chen's blog[^] for a detailed explaination of why not.
|
|
|
|
|
I'm a newbee with MFC. I'm following this article on Worker Threads:
http://www.codeproject.com/threads/usingworkerthreads.asp[^]
With the following code I'm getting the following error. Any suggestions as to what is going on here?
: error C2665: 'AfxBeginThread' : none of the 2 overloads can convert parameter 1 from type 'void (void)'
<br />
<br />
#include "stdafx.h"<br />
#include "canmon.h"<br />
#include "getcanmessages.h"<br />
<br />
#ifdef _DEBUG<br />
#undef THIS_FILE<br />
static char THIS_FILE[]=__FILE__;<br />
#define new DEBUG_NEW<br />
#endif<br />
<br />
<br />
static UINT run(LPVOID p);<br />
void run();<br />
volatile BOOL running;<br />
<br />
Cgetcanmessages::Cgetcanmessages()<br />
{<br />
}<br />
Cgetcanmessages::~Cgetcanmessages()<br />
{<br />
}<br />
void Cgetcanmessages::gogetcan()<br />
{<br />
running = TRUE;<br />
AfxBeginThread(run, this);
}<br />
<br />
UINT Cgetcanmessages::run(LPVOID p)<br />
{<br />
Cgetcanmessages * me = (Cgetcanmessages *)p;<br />
me->run();<br />
return 0;<br />
}<br />
<br />
void Cgetcanmessages::run()<br />
{<br />
}<br />
<br />
|
|
|
|
|
See here.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Freddie Code wrote:
static UINT run(LPVOID p);
void run();
volatile BOOL running;
I suggest you rename the second function above. There are two functions named run(). One is UINT run(LPVOID) and the other is void run().
Rename the void run() to anything else because the compiler is getting confused.
this is this.
|
|
|
|
|
Why does the following code, when running, causes some programs to hang while starting (before presenting any UI), including Windows Explorer/Internet Explorer (when double-clicking an HTML file in Windows Explorer) and the AnalogX PacketMon installer[^]?
#include <iostream>
#include <tchar.h>
#include <windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
HWND gWnd = CreateWindow(_T("STATIC"), _T("SomeWindow"), WS_POPUP, 20, 20, 200, 200, 0, 0, 0, 0);
getchar();
return 0;
}
|
|
|
|
|
Why are you trying to create a GUI component in a console application?
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I'm using a library (not easily modified) that does that call. If I change "STATIC" to "STATIC_" (or probably anything else), the problem disappears.
|
|
|
|
|
What exactly is it that you are trying to do? CreateWindow() is a GUI, not a console, function that creates a window. It also sends messages (something that a console application knows nothing about) to the window's procedure.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I know it's not proper, but it's in a (internal) library that would be hard to modify. Because using something other than STATIC doesn't appear to cause problems, it seems like there might be a way to get it to work (a define? another header file?). I basically just want to understand why using STATIC causes problems and using anything else doesn't cause problems. I like to know the causes of problems, not just the solutions.
|
|
|
|
|
IGx89 wrote:
Because using something other than STATIC doesn't appear to cause problems...
Have you entertained the thought that "doesn't appear" might be the key phrase here? Just because you do not see a problem does not mean a problem ceases to exist.
IGx89 wrote:
I like to know the causes of problems, not just the solutions.
Unless you have not shown all of the code, you're trying to solve something that is the product of a bad design. Why are you trying, or even thinking that it's possible, to create a static window from within a console application?
Much the same result can be achieved by trying to use getch() or printf() in a GUI application. Yes it might compile/link fine, but a "crash" of some sort is emminent.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
|
Can you elaborate on that?
|
|
|
|
|
It is to do with resource ID numbers, STATIC is used to define the resource id for static labels on forms.
The tigress is here 
|
|
|
|
|
 "STATIC" is the type (e.g., listbox, button, edit) of window that is to be created. It is one of many predefined system classes. In his call to CreateWindow(), 0 (the 9th parameter) was used as the control id.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
I don't believe that resource-ids are the problem:
The control/resource-id is specified as the 10th parameter to CreateWindowEx.
The STATIC you are seeing is the name of the window-class to create a window from - in this case, a static-control - so no problem there.
Changing the text to _STATIC_ results in an invalid class-name and CreateWindowEx fails (returns NULL) so no window is created.
I think the problem with the program is that a console-program does not run a message-pump, so it cannot receive or process windows messages. So all messages destined for the STATIC control do not get processed and the program/Windows hangs indefinitely.
Solution: create separate thread to handle the GUI and create a message-pump (GetMessage/DispatchMessage) to handle GUI messages.
or better yet, use a GUI program that's what they're meant for.
James
http://www.catch22.net
|
|
|
|
|
Ok, thanks! That's exactly the detailed explanation I was looking for  .
It's nice to know about things not to do, but it's even nicer to know exactly why not to do them.
|
|
|
|
|
Hey,
maybe someone could help with this one... and yes I did look in the archives for help but failed to find any...
so, I am trying to read a file. It gets opened OK, the size is checked OK... then I call fread for 1 byte and it blows up...
the thing is also that these files are supposed to be cached. At the beginning only the directory structure is cached and the file names/info, but not the file contents itself, until the file is actually accessed, or so it seems. The cache is disk based, and if it helps at all, it is created by PointSoft Jukebox manager. It is just a software that drives a big DVD jukebox where the data that I need is read from....
is there any method or anything that would overcome this? I have also tryed unbuffered and buffered reads...
...or maybe I am just doing something stupid that I fail to see?...
<br />
FILE* file = fopen( m_oblFileName, "rt" );<br />
<br />
if( file==NULL ) <br />
{<br />
return false;<br />
}<br />
<br />
DWORD dwFileSize=GetFileLength(m_oblFileName);<br />
<br />
if (dwFileSize<1)<br />
{<br />
return false;<br />
}<br />
<br />
char chTmp;<br />
if (0>=fread(&chTmp,1,1,file)){<br />
return false;<br />
}<br />
else<br />
fseek(file,0,SEEK_SET);<br />
<br />
CString strLine;<br />
while(ReadLine(strLine, file)>0)<br />
the other two lame functions that I used, but dont seem to be relevant because they do not crash
<br />
long GetFileLength( LPCTSTR szFileName )<br />
{<br />
long length=0;<br />
int handle = _open( szFileName, _O_RDONLY );<br />
<br />
if( handle!=-1 ) <br />
{<br />
length = _filelength(handle);<br />
_close(handle);<br />
}<br />
return length;<br />
}<br />
<br />
int ReadLine(CString &strLine, FILE *pFile)<br />
{<br />
char mmm[2]={0};<br />
CString strTemp;<br />
<br />
while((mmm[0]!=10))<br />
{<br />
if (fread( mmm, 1, 1,pFile)!=1)<br />
{<br />
if (feof(pFile)&&(strTemp.GetLength()>0))<br />
break;<br />
<br />
fclose(pFile);<br />
return -1;<br />
}<br />
<br />
mmm[1]=0;<br />
strTemp+=mmm;<br />
}<br />
<br />
strLine=strTemp;<br />
<br />
strLine.TrimLeft("\n\t\r");<br />
strLine.TrimRight("\n\t\r");<br />
<br />
glb_Log.DebugLog2(TRUE,"ReadingLine = '%s'",strLine);<br />
<br />
return strLine.GetLength();<br />
}<br />
|
|
|
|
|
The first thing I would do is remove, or at least comment out, the GetFileLength() function. Mixing streams and handles is not a good idea at this point. It serves no purpose in trying to figure out why fread() is not working, and anything you can do to make the problem set smaller is only going to help you in the long run.
sfeldi wrote:
if (0>=fread(&chTmp,1,1,file)){
Even though a char is one byte, I would change this to:
fread(&chTmp, sizeof(char), 1, file); That said, why are you not using CFile or CStdioFile? You'll save yourself a lot of time and grief by doing so.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
why are you not using CFile or CStdioFile?
don't know about the original poster, but I don't use them because i don't use MFC in every project.
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
But since he has already indicated that it is an MFC application, it only makes sense to use them. Incorrectly mixing streams and handles with MFC (which uses its own streams and handles for file I/O) is a recipe for trouble.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
But since he has already indicated that it is an MFC application, it only makes sense to use them
not really a great reason, IMO. ex. i almost always use C-style streams 1) because i'm not always using MFC and 2) because i'm more comfortable with them than i am with MFC's wrappers and 3) i simply don't like MFCs file classes. i also mix STL collections and algorithms in with MFC (std::string, even). are you prepared to say we shouldn't use std::vector since MFC has CArray ?
Cleek | Image Toolkits | Thumbnail maker
|
|
|
|
|
Chris Losinger wrote:
3) i simply don't like MFCs file classes.
Why? What is it that they do/don't do that C-style streams do?
Chris Losinger wrote:
are you prepared to say we shouldn't use std::vector since MFC has CArray ?
Most assuredly, if it causes problems. You are getting a bit off topic here, Chris. The OP is obviously doing something that he is none too comfortable with and has little experience using. The solution in this case is to always scale the problem down to something much smaller than the original, hence my suggestion to remove the GetFileLength() call. My other suggestion, again to simplify things, was to remove the FILE* and handle-related code and use CFile or CStdioFile instead. Those two things alone will go a long way in uncovering the problem.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
