|
LCI wrote: ...at the same time, include controls like buttons drop down boxes, picture control area.
In the menu, or the client area?
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Well, in the client area. I suspect that if i create an MFC Single or multiple document application, i will get the menu. But if i do that. Now i have a menu, but i want to be able to add controls and buttons in the client area just like i would in a dialog based application.
Do you recommend me generating the project as a win32 project?
I am currently creating projects of different types just to see if i can get a feel for doing the above but cannot seem to figure it out.
|
|
|
|
|
LCI wrote: Well, in the client area.
Then just derive the view from CFormView.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
I really need help on this one.
I have a VS6 app that I loaded in VS.NET 2003. Convertion ok, compile ok, runs ok.
Now, I don't know what happend but the control IDs dont get listed in the events pane of dialog properties. Also, if I choose 'Add variable' from the context menu after right clicking a control, the add variable dialog does not allow me to add a 'control' variable. The "Control variable" check box is disabled.
Looks like some link between the resoirce IDs and the dialog properties in VS is broken.
Hope I explain this clearly enough.
Anyone has an idea why this is happening, I been on this probleme for quite a while and really need a way to fix this. ?
Louis
* google is your friend *
|
|
|
|
|
Since your problem is difficult to reproduce, I would suggest you to perform a test: make a simple new application in VS 6 (of the same type -- MDI, Dialog-based, etc.), and then convert it to VS 2003 (hope you have VS 6). Then see if the same problem appears.
I think the problem can be caused by some missing special comments (like "//{{AFX_MSG", used widely by older VS wizards) accidentally deleted from source files.
|
|
|
|
|
Hi,
If I remember, I think that it was working at some point. So, for sure, I must have broken something. I have other apps that I converted and I dont have this problem.
I have been comparing with other projects t osee what can be different but with no avail.
If I'm not mistaking, the "//{{AFX_MSG" and others similar, are not used anymore by VS.NET. So even if they are not in the source file it wont affect. In fact, new classes created for new dialogs dont have any of those special comments (tags).
Heres some more info.
If I click a control on a dialog form to select it, then the event pane in the properties fills with the pssible notification messages for that control. This works normally. If there is a function handler to a notification message it is also listed. I can also add a new handler to the seelcted control this way.
Control Ids dont get listed only when the dialog is selected, when usually all the control IDs would appear.
The biggest problem I have with this, and which is causing me a lot of delays, is that I cannot add control variables.
Louis
* google is your friend *
|
|
|
|
|
Finally found the problem, so I post the solution here for anyone else that would stumble on this problem.
My original project was a VC6 project. It was converted by VC7. At this point I think resources were ok. I was using two resource files in this project, just to split them up so it is easier to work in a team environnement. I also was including a resource file from another project which is a global library for many of our projects.
I am not to sure how the problem occured, but the project lost track of which of the resource file was the main resource file. The main resource file is saved in the .vcproj file. At the end of this file there is a <Globals> then a <Global> section in which the main resource file path appears. Mine was pointing to the wrong one, after putting back the proper path, everything was back to normal.
Took me a while to find this after trying several things.
Case closed.
Louis
* google is your friend *
-- modified at 10:51 Tuesday 11th July, 2006
|
|
|
|
|
We are creatng an application that hooks up event sinks to IE html elements.We want to start with sinks for html text boxes only;and later proceed on to include sinks for other elements.
For this we plan to have a static registry which contains key-mapped Classfactory instances.
A typical entry in our case can be HTMLTextElement vs. ClassFactory instance for the HTMLTextElement sink.
This will be inserted into the registry as part of the static initialization of the classfactory.
When a html page containing text elements is invoked,the classfactory instance from the registry will be returned corresponding to the key.
This will be used to create and hook up an instance of the listener.
Can someone give a pointer on how to implement the above concept in ATL?
|
|
|
|
|
How to make a process foreground.
Krishnakumar
|
|
|
|
|
|
What do you mean by "foreground process?" Windows does not have the concept of foreground/background processes. This is a concept from platforms such as Unix.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
It does. Just not exactly in the *nix sense.
@Topic
Basically, if you start a program - either under Unix or Windows - its a foreground-process. Its the background-processes which need special consideration.
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Sebastian Schneider wrote: Its the background-processes which need special consideration.
Windows does not have "background processes." Please explain what you are referring to.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
My problem is that, I want to make a window active ( foreground ).
When i do this, the window icon in the taskbar is flashing.
Not getting exact focus.
(Used function 'SetForegroundWindow()')
Please comment
Krishnakumar
|
|
|
|
|
This behavior is by design (for Windows 2000). Instead of bringing the window to the front, it simply calls FlashWindow(). As a workaround, try:
if (GetForegroundWindow() != hWnd)
{
DWORD dwThreadID1 = GetWindowThreadProcessId(GetForegroundWindow(), NULL);
DWORD dwThreadID2 = GetWindowThreadProcessId(hWnd, NULL);
if (dwThreadID1 != dwThreadID2)
{
AttachThreadInput(dwThreadID1, dwThreadID2, TRUE);
SetForegroundWindow(hWnd);
AttachThreadInput(dwThreadID1, dwThreadID2, FALSE);
}
else
SetForegroundWindow(hWnd);
if (IsIconic(hWnd))
ShowWindow(hWnd, SW_RESTORE);
else
ShowWindow(hWnd, SW_SHOW);
}
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
I tried.
But now also the window (in tastbar icon) is flashing ( not getting the focus ).
Krishnakumar
|
|
|
|
|
What if you do the following prior to calling SetForegroundWindow():
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID) 0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Would a Win32 Service be considered a type of "background process" (quotes intentional), akin to dæmons (demons) in *nix?
Peace!
-=- James
If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
DeleteFXPFiles & CheckFavorites (Please rate this post!)
|
|
|
|
|
Win32 services are similar to Unix daemons, but it is not the same concept as "background processes"
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
-- modified at 10:55 Friday 2nd June, 2006
|
|
|
|
|
I just checked:
Windows allows you to optimize your computer for "Application" or "Background Services" (German Windows XP Pro). Ill admit that services are more likely the "Windows version" of "system daemons".
But, well, if you are not using an applications windows, it will literally be "behind" another application. You are unable to use that application until you click its windows and thus "bring it to the front".
And that is just what background processes under *nix are like: You specifically put them in the back to use another application and be able to return to them later on without restarting them from scratch.
I admit that "foreground processes" and active windows / "background processes" and inactive windows do not follow the exact same definitions under *nix and Windows, but they are similar enough to use the term".
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
There are subtle differences between an application that does not have the focus in Windows (which you are equating to "background") and actually backgrounding an application in a *nix system.
In Windows, you cannot pause an application that was started on the command line and then tell it to resume in the background (that is, without control of stdout). On top of that, you cannot tell the very same application that you want to have it resume control of the console (stdout).
Effectively, all processes in Windows are background applications. That is, when you double click their icon to start them up, they don't have a stdout. When you do start an app from the command line (assuming it is a GUI), it doesn't have a stdout by default (though, you can jump through some hoops to give it one).
The concept of "foreground" is different in Windows as well. The foreground application in Windows is whatever application has the current focus. This isn't the case in *nix systems, where you can have as many foreground applications as you have consoles open for.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
I know. However, this just refers to the ability to easily put an application into the background or pull it into the foreground.
However, there are application which do not have a visible Window, namely the "iconified" programs (such as ZoneAlarm, QuickTime Helper, ATI Catalyst Control Center, Antivirus SW, etc.) - and not all of those are service-GUIs.
This really is more like a religious thing, so I will stop now.
Basically, I'd even say that EVERY program you are not using is a background process - just because there is only a single input-focus, and thus, only one application is active - or "in the foreground".
I am not claiming that Windows can do everything Linux can - or vice versa. I am just saying that "foreground", "background" and "process" are not Linux-specific concepts. Just that the implementations vary.
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
I didn't mean to imply that I was debating you. I understand what you were getting at. I was simply stating that the 2 OS's define these terms (and hence the implementation of those features) differently. When going between systems, it is important to note the differences. You will run into areas where they are not synonomous quite often in low level coding, but if you just view it from a high level point of view, you can ignore those differences.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Me neither. I just thought I had made an ambigious statement and wanted to clarify.
I am not a native speaker, and I am really careful not to set people off just because my statements could be misunderstood (because, if they can, they will be  ).
Cheers,
Sebastian
--
Contra vim mortem non est medicamen in hortem.
|
|
|
|
|
Sebastian Schneider wrote: Just not exactly in the *nix sense.
What do you mean by that?
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
