|
Well, yes that sounds like that will be the next problem and answer. If I try to use (open project) from the start page, it only shows exstentions for the VB.Net that I have on the computer with the C++. It doesn't show C++ exstentions at all. If however I click on a file like duolphase.C , it will display it in visual studio but there are no controls avalable to edit the program. I mean no tabs, no controls at all.
I tryed to set options-environment but found nothing refering to the start page that made any difference. The only thing I can figure is I'll have to type it in as a new project and go from there. Like the header file thing you mentioned.
Wander what would happen if I rename xxxxxx.C to xxxxxx.cs ??
Tryed posting in the VS forum but no answer as yet.
In case your wandering, yes there is a comercial app in the works and a gui-servo&stepper motor app for public domain.
Thanks for the help.
Gyrogearloose
|
|
|
|
|
AAAhhh I got it! Use main menue not the open project tab.
File-open-openfile After it opens in the environment use start without debug . Using Start brings up an error message about it being an a bynary code it don't know. Then it will try to run, ( mixed results) but it does run.
Renaming the file didn't seem to make any difference. Soooo this means the next step is to type it into a new project so debug can handle it.
Small steps guys,small steps.
Gota keep reading this forum. Tons of info.
Gyrogearloose
|
|
|
|
|
I've recently updated one of my MFC applications to use the serialization functions available in CImageList (CImageList::Read and CImageList::Write).
The problem I'm having is, my application must run under both WinNT and WinXP.
When a file is saved under WinXP, the file is no longer readable under NT. I get an unexpected file format error, and the way the CImageLists are being saved seem to be the culprit.
Does anyone know what I can do to make the Image list serialization functions work the same under both operating systems?
|
|
|
|
|
When you save on XP you're getting a v6 format file, which is not readable by previous OSes. Use ImageList_WriteEx() and pass the ILP_DOWNLEVEL flag to save in a format that previous OSes can read.
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
"die"
ahhhh!
"diet"
AAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!
|
|
|
|
|
Recap from the title :
I'd like to hide my console-based app from the windows taskbar.
(Basicly once executed, it should just run permanently in the background without bothering me with it's window )
Anyone got any idea how to do this on WinXP ?
(I've searched for it but all I / Google could come up with was stuff that worked on Win9X... I'm proably looking in the wrong direction.. )
|
|
|
|
|
so the W98 stuff does not work in XP ?
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
I dont think you can do that by directly executing the console app.
You can do it by launching the console app from a windows app using createprocess and setting shownowindow* styel..
*I dont remember exactly the bit name but you can find out in the MSDN.
MSN Messenger.
prakashnadar@msn.com
Tip of the day of visual C++ IDE.
"We use it before you do! Visual C++ was developed using Visual C++"
|
|
|
|
|
call GetConsoleWindow() to get the console window handle and then ShowWindow(SW_HIDE) to remove it from windows taskbar.
Gurmeet S. Kochar
If you believe in God, it's because of the Devil
|
|
|
|
|
Environment: Windows 2000 Professional, VC++ 6
I am trying to trap the loss of focus on a dialog box in order to close it. Initially I thought that I could handle WM_KILLFOCUS or WM_ACTIVATE. Unfortunately these are not being fired as I expected.
My next approach used SetCapture to detect mouse down events outside the dialog. While it works well for that, it breaks the control notification messaging (e.g. BN_CLICKED): they are no longer fired.
Can anyone suggest a way around this or another approach? It seems like there should be a standard way to do this.
thanks,
Mike Thompson
|
|
|
|
|
|
I've tried it both ways. It started out modal but I made it modeless in the hope that I'd see WM_KILLFOCUS or WM_ACTIVATE at other times. No such luck.
thanks,
MT
|
|
|
|
|
I tried the following and it actually works:
void CDlgFocusTestDlg::OnActivate(UINT nState, CWnd* pWndOther, BOOL bMinimized)
{
if (nState == WA_INACTIVE)
EndDialog(IDOK);
else
CDialog::OnActivate(nState, pWndOther, bMinimized);
}
Hope, this will solve ur prob
Gurmeet S. Kochar
If you believe in God, it's because of the Devil
|
|
|
|
|
My problem with WM_ACTIVATE is that it is fired only when switching to another application. My application is full-screen and the dialog box is in a DLL loaded by the application. There is only our full-screen application to click on, so WM_ACTIVATE isn't fired.
thanks,
Mike Thompson
|
|
|
|
|
BTW, i tried it with modal dialog box
Gurmeet S. Kochar
If you believe in God, it's because of the Devil
|
|
|
|
|
how do i execute an external program with arguments using standard ansii c? this is a 16bit dos application so i can't use any windows libraries.
thanks,
Rob Tomson
--
There are 10 kinds of people. Those who understand binary and those who don't.
|
|
|
|
|
spawn?
onwards and upwards...
|
|
|
|
|
i tried that but it doesn't seem to be in the standard c libraries.
Rob
--
There are 10 kinds of people. Those who understand binary and those who don't.
|
|
|
|
|
exec(...) ??
MSN Messenger.
prakashnadar@msn.com
Tip of the day of visual C++ IDE.
"We use it before you do! Visual C++ was developed using Visual C++"
|
|
|
|
|
Hello.
I am working on a small socket application that utilizes SSL and FTP protocol.
The problem is that the server response with error:
"503 Log in with USER first."
The SSL is OpenSSL. Here is an overview of the sequence.
- winsock connect
- AUTH SSL
- SSL_connect()
- handshake is success
// At this point, everything is send/recv via SSL
// SSL_send() and SSL_recv()
- PBSZ 0
- PROT P
- USER <username>
- PASS <password>
...
// All the above are successful
// Server respond "230 <username> logged in."
// Every command afterward returns an error
- SYST
Basically, every command the program sends, the server would return "503 Log in with USER first."
Do you need to package outgoing data in a special SSL package before passing it to SSL_send()?
Please post if you have any idea.
Thanks,
Kuphryn
|
|
|
|
|
I'm still having trouble with this. I have a dll that uses the WM_COPYDATA to send a struct to a mainframe window. The struct has some longs (4 I think) and a char[256]. This has been working and does work on about 90% of PC's. A few customers and some in-house people do not see the text that is being passed.
After checking into it, I have found that the pointer to the lpCopyDataStruct is not correct on the machines that have the problem. I can see where my struct begins by doing a memory dump starting at the erroneous pointer and it is there but much further down the line (maybe 40-50 bytes?)than where the pointer says it should be.
Can anyonne think of a reason why this works most of the time but fails on certain PC's? I have reports that some NT, 2000, and XP machines have this trouble but not everyone with those OS's have the problem.
Uuugh!!
Thanks,
Dave
|
|
|
|
|
is it possible they have those fancy clipboards running where u can have many virtual clipboards and select between them?
u prolly thought of that already right?
"there is no spoon" biz stuff about me
|
|
|
|
|
I'm not sure what that is. I'll see if I can find more info on it. Does that affect how the WM_COPYDATA message works?
|
|
|
|
|
yes it can
check to see if they have any non-standard or enhanced clipboards utilities or anything like it
"there is no spoon" biz stuff about me
|
|
|
|
|
Here's what fixed the problem:
We noticed that two copies of Rundll32.exe were running and when they were killed, things worked. We looked into what was causing the Rundll32 to be executed and found that the tray application for the NVidia software was responsible. Once that was removed from the startup, things worked fine on both PC's where the trouble was reported. Those people can no longer use the tray app for the video card but they didn't need it.
So, do you think it's something NVidia is doing, RunDll32, or just Windows that is at the root of the problem? Why would my pointer being passed in WM_COPYDATA get corrupt due to this app running?
Thanks for your help,
Dave.
|
|
|
|
|
Is there any way of finding out if a shell open of a file (double clicking a file) has occured in a program.
Thanks you
|
|
|
|