|
Does any one know how to write a tftp client program using udp
socket programming?
Cheyi
|
|
|
|
|
|
Thanks, I did but there was nothing on tftp.
|
|
|
|
|
Hi to everyone, I connect locally to SQL Server 2000, using ODBC, without
problem. The problem is that I cannot connect to the SQL Server via a LAN.
How can I connect to SQL Server from a second PC via a network (with ODBC)?
Thank you!!!
|
|
|
|
|
I wonder if somebody could point me in the right direction.
I have a dialog containing a listview and a richedit control. Both of the cover nearly the whole dialog. Now I just had a great idea. Wouldn't it be more visually pleasing if the user was able to resize the controls. So I guess I need something inbetween the controls which the user can can drag, at the same time resizing the controls. Something similar to how the internal windows work inside MSVC.
I have seen this done in plenty of programs, but how did they do it?
|
|
|
|
|
waldermort wrote: I have seen this done in plenty of programs, but how did they do it?
it's called magic.
MFC does not have an automatic resizing framework ( me think it's one of its failing ) to be able to easilly resize dialogs ( mostly ) and their contents. Why ? ( my interpretation of it ) Because the resource editor is not pixel oriented, it's based on DLU ( dialog logical unit ) which lets the system do some resizing depending on the size of the font scaling ( big font vs. normal font ) and that once a dialog is designed, it's not easy to translate to pixel and keep the exact positioning.
ok, so, now, how is it done ? for simple layouts, manual resizing and positioning of the control is easy to do, handle the WM_SIZE message and recompute each control position and move them to position with do MoveWindow ( or SetWindowPos ).
for more complex layout, you can still do it manually, or you can go have a look at different resising classes and framework that exists, do a little search here on codeproject to find a couple of them. in general, each work well, but I think that they all have some sort of limitation that makes layout difficult.
At work, We are using the LayoutManager of Dundas, which works ok for some layout, but is a nightmare for others.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
But I thought the WM_SIZE message was sent when the size of the dialog is changed. I have already implemented resizing and reposition on the WM_SIZE, but the controls will always have a position and size relative to the edges of the dialog.
What I am trying to do is resize the Child windows on the dialog, without the dialog itself being affected. In theory one child window would become larger while the other becomes smaller to give space. I'm guessing I would need to place some sort of control bar between the two controls, and handle a mouse event for it. Though I know of no such control.
To make things even more difficult, this is a non MFC project.
|
|
|
|
|
There is an article here on CP about a splitter bar for dialogs that does not require the child controls to be CView derived. You can have a look for it here[^]. It may fit your purpose.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
Thanks for the suggestions. I have looked through and downloaded all of the splitter bar articles here on CP, all of them use MFC in some form or another. Either the control is derived from CView, CDialog, CSplitter or CWnd. Also after reading through the source codes, I think it would be a great task trying to convert them to a non-MFC project.
There is one article however, which deals with anchoring and resizing controls in non-MFC. Controls are usually anchored against the edges of the dialog, whereas here I would need to anchor the controls against each other, at the same time creating a splitter control.
It's a large task to incorporate into my nearly finished project, maybe I will just leave it for version 2. My boss is already complaining about the time.
|
|
|
|
|
I am writing an OpenGL program in visual c++.NET and I am reading a file and using the file as a texture. After I build the program using
Release build" and run the program by double clicking on it in windows explorer, everything works fine, but if I try to run the same program using debug->start from the visual studio menu bar, the texture file won't load. Is this a problem with my code or is visual c++ not loading the file on purpose.
pplshero54 gives his most thanks
|
|
|
|
|
#include "stdafx.h"
#include <windows.h>
int _tmain()
{
HANDLE hProcess;
DWORD Address;
hProcess = OpenProcess(PROCESS_ALL_ACCESS, TRUE, (DWORD)6E8);
if (hProcess == NULL)
{
printf("Main - hProcess Error.");
CloseHandle(hProcess);
return 0;
}
Address == VirtualAllocEx(
hProcess,
NULL,
sizeof("C:\\mydll.dll"),
MEM_COMMIT,
PAGE_EXECUTE_READWRITE);
if(Address == NULL)
{
printf("Main - VirtualAllocEx Error(return NULL).");
CloseHandle(hProcess);
return 0;
}
printf("Address: x%", Address);
if(WriteProcessMemory(hProcess,
(PVOID)Address,
"C:\\mydll.dll",
sizeof("C:\\mydll.dll"),
NULL) == NULL)
{
printf("Main - WriteProcessMemory Error (return NULL).");
CloseHandle(hProcess);
return 0;
}
CreateRemoteThread(hProcess
, NULL
, 0
, (LPTHREAD_START_ROUTINE)GetProcAddress(GetModuleHandle(TEXT("kernel32")), "LoadLibraryA")
, (LPVOID)Address
, 0
, NULL);
CloseHandle(hProcess);
return 0;
}
---------------end----------------
I get this error:
error C3861: 'VirtualAllocEx': identifier not found, even with argument-dependent lookup
warning C4312: 'type cast' : conversion from 'DWORD' to 'PVOID' of greater size
warning C4312: 'type cast' : conversion from 'DWORD' to 'LPVOID' of greater size
thx
thx
|
|
|
|
|
Did you install the latest Platform SDK? VirtualAllocEx should be defined in winbase.h which is included by windows.h.
DWORD Address;
to
LPVOID Address;
Address == VirtualAllocEx(
to
Address = VirtualAllocEx(
|
|
|
|
|
Thx for your replay. I got rid of the two warnings but am still stuck with the error (error C3861: 'VirtualAllocEx': identifier not found, even with argument-dependent lookup). I have vertion Microsoft Visual C++ .NET. Eny more advice??? please??? thx Glich
|
|
|
|
|
From MSDN:
Requires Windows Vista, Windows XP, Windows 2000 Professional, or Windows NT Workstation 4.0.
Server Requires Windows Server "Longhorn", Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0
That means you need to set WINVER macro to a version that would include VirtualAllocEx declaration.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Thx for your help.
I have tryed it with: "#define WINVER 0x0400" as http://msdn2.microsoft.com/en-us/library/6sehtctf.aspx
suggests but there is no diference. these are my command line options: "/D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_MBCS" /Gm /EHsc /RTC1 /MLd /Yu"stdafx.h" /Fp"Debug/InjProg.pch" /Fo"Debug/" /Fd"Debug/vc70.pdb" /W3 /nologo /c /Wp64 /ZI /TP" and these are my linker command line options: "/OUT:"Debug/InjProg.exe" /INCREMENTAL /NOLOGO /DEBUG /PDB:"Debug/InjProg.pdb" /SUBSYSTEM:CONSOLE /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib"
eny help to help me?  thx!
|
|
|
|
|
glich wrote: I have tryed it with: "#define WINVER 0x0400"
Where did you put this definition? It must be defined before windows.h is included. If you use precompiled headers, it is best to put it at the top of stdafx.h. Or just add it to the Project settings.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Thx for your replay.
It still does not work even after I placed the line "#define WINVER 0x0400" as the first line.
More help is needed if posible. Thx again.
|
|
|
|
|
Actually, it _WIN32_WINNT that has to be 0x0400. WINVER 0x0400 is the code for windows 95.
#define _WIN32_WINNT 0x0400
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
adfasdf
Pravin Parmar,
PravinParmar.ce@gmail.com
|
|
|
|
|
i want to check thread is running state or not and if it is running then terminate this thread and start another thread.
anybody have idea about this please share with me:its urgent
Bankey Khandelwal
Software Engineer
|
|
|
|
|
To check if thread is still running
<br />
bool IsThreadRunning(HANDLE hThread)<br />
{<br />
DWORD dwExitCode;<br />
::GetExitCodeThread(hThread, &dwExitCode);<br />
return (dwExitCode == STILL_ACTIVE)? true : false;<br />
}<br />
Don't try to terminate the thread using TerminateThread(), either have a flag or event that the thread checks to see if it should terminate gracefully. Frankly I think it's better to reuse the thread...
|
|
|
|
|
To tell if a thread is running or not:
DWORD dwState = WaitForSingleObject(hThread, 0);
switch(dwState)
{
case WAIT_TIMEOUT:
break;
case WAIT_OBJECT_0:
break;
}
The solution using the GetExitCodeThread API has a flaw. From MSDN:
"Warning: If a thread happens to return STILL_ACTIVE (259) as an error code, applications that test for this value could end up in an infinite loop."
In general there is no safe way to forcefully terminate a thread (although this doesn't seem to stop people from doing it) - Doing so, by calling TerminateThread for example, can put the process into an unstable state. One way this happens is as follows:
1. The thread about to be terminated calls an API which enters a critical section by calling EnterCriticalSection.
2. It is terminated before it can call LeaveCriticalSection.
3. Another thread calls the same API and it deadlocks: This API is now broken and any thread calling it will now deadlock.
This really happens and I can tell you from experience that tracking down the problem is not pleasant.
The general solution to this problem is to program the thread so you can arrange for it to exit, typically by signaling an event and then waiting for it to terminate.
Steve
|
|
|
|
|
Ah. I've never noticed that little caveat since I don't usually return anything other than 0 for my threads. Guess you learn something new everyday...
|
|
|
|
|
hfry wrote: I don't usually return anything other than 0 for my threads
Returning ZERO signals thats your thread is successfully closed
|
|
|
|
|
ThatsAlok wrote: Returning ZERO signals thats your thread is successfully closed
This need not be the case: The programmer is free to place whatever interpretation on the exit code of a thread that is appropriate for his application. 0 for success is simply the most popular. For example you could use the return code to return the result of a computation.
Steve
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
