"Legacy" WinForm .NET Applications
-
jdunlap, I doubt that I understand your concept of most of the controls are lightweight (windowless), because as far as I know from "unmanaged" ActiveX Controls world: there is a clear definition of Windowless Controls/Containers, and as far as I know they are not supported in .NET (correct me if I'm wrong here). Yes, you are right that you may continue developing GUI components and they will hopefully work. However, Just imaging GUI architecture that includes GUI contatiner with ability of dynamic content insertion. Are you ready today to come up with such architecture? Are you sure it will be optimum for Longhorn GUI capabilities? Or, you will be just spending resources right now to find later that they were waisted? I'm not talking about learning here: do it, no questions. I'm talking about spending your money on something that maybe rendered as old in just 2 years. Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: I doubt that I understand your concept of most of the controls are lightweight (windowless), because as far as I know from "unmanaged" ActiveX Controls world: there is a clear definition of Windowless Controls/Containers, and as far as I know they are not supported in .NET (correct me if I'm wrong here). They aren't. But we are making support for them. There will be some basic window classes such as ChildWindow, PopupWindow, and DockingWindow. They will implement the IWindow interface, and will host the lightweight controls. If you want to put a lightweight control on a normal WinForms form, you place a ChildWindow on your form, and change its Child property to an instance of the class you want to use. igor1960 wrote: Are you ready today to come up with such architecture? Yes. igor1960 wrote: Are you sure it will be optimum for Longhorn GUI capabilities? If they have a similarly advanced GUI system, then we will be duplicating their work (but I highly doubt that they will). Otherwise, our system should integrate well.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
I'm lazy to respond, but I'm sure you understand that in 2 years GUI architecture/implementation may become quite different then the one we have today. Sure, yours .NET WinForm app will work -- but would it be "cutting edge" by then? From that presentation it's obvious: it would be not! Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
Well, I think it's more like 3 years ;) When was the last time you saw MS release on schedule? Anyway, no one really know what happens to the Longhorn GUI, as we have seen many times before, it might change a few times mebore it's released. Hmmm, if I had to think about if my app's got obsolete in 2 - 3 years I could not write anything. 2 - 3 years is a looooong time in this business, and if you are afraid to make app's now, because there comes a new Windows GUI in 2 - 3 years, then have fun doing nothing for a couple of years. - Anders Money talks, but all mine ever says is "Goodbye!" http://SourceLocker.net[^] SourceControl and DefectTracker Project. nsms@spyf.dk <- Spam Collecting ;)
-
igor1960 wrote: I doubt that I understand your concept of most of the controls are lightweight (windowless), because as far as I know from "unmanaged" ActiveX Controls world: there is a clear definition of Windowless Controls/Containers, and as far as I know they are not supported in .NET (correct me if I'm wrong here). They aren't. But we are making support for them. There will be some basic window classes such as ChildWindow, PopupWindow, and DockingWindow. They will implement the IWindow interface, and will host the lightweight controls. If you want to put a lightweight control on a normal WinForms form, you place a ChildWindow on your form, and change its Child property to an instance of the class you want to use. igor1960 wrote: Are you ready today to come up with such architecture? Yes. igor1960 wrote: Are you sure it will be optimum for Longhorn GUI capabilities? If they have a similarly advanced GUI system, then we will be duplicating their work (but I highly doubt that they will). Otherwise, our system should integrate well.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiThey aren't. But we are making support for them. There will be some basic window classes such as ChildWindow, PopupWindow, and DockingWindow. They will implement the IWindow interface, and will host the lightweight controls. If you want to put a lightweight control on a normal WinForms form, you place a ChildWindow on your form, and change its Child property to an instance of the class you want to use. That exactly proves my point. I'm not saying that what you are doing is wrong: I'm just stating that MSFT maybe doing the same thing, but a little bit differently. When we are talking about GUI container with dynamic content, we usually mean that there is an infrastracture that supports search and identification of that content. For example, in OLE containers we have OLE infrastracture that supports Insert Object functionality: "Control","Insertable" registry entries. SO, what do we have in .NET, GAC? So, should I write my container that will enum assemblies in GAC and find the ones that have Control as a base class, or as you propose ChildWindow, PopupWindow, and DockingWindow? What exactly? And what if tommorow MSFT comes up with different mechanism? WHat if tommorow we shouldn't be looking in GAC at all, but instead navigate to some remotely central place? Any answers? If they have a similarly advanced GUI system, then we will be duplicating their work (but I highly doubt that they will). Otherwise, our system should integrate well. What if they will? And what if theres is better?... Or worse, but they have a power of marketing anything they want? And let me tell you -- they do have this power... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
They aren't. But we are making support for them. There will be some basic window classes such as ChildWindow, PopupWindow, and DockingWindow. They will implement the IWindow interface, and will host the lightweight controls. If you want to put a lightweight control on a normal WinForms form, you place a ChildWindow on your form, and change its Child property to an instance of the class you want to use. That exactly proves my point. I'm not saying that what you are doing is wrong: I'm just stating that MSFT maybe doing the same thing, but a little bit differently. When we are talking about GUI container with dynamic content, we usually mean that there is an infrastracture that supports search and identification of that content. For example, in OLE containers we have OLE infrastracture that supports Insert Object functionality: "Control","Insertable" registry entries. SO, what do we have in .NET, GAC? So, should I write my container that will enum assemblies in GAC and find the ones that have Control as a base class, or as you propose ChildWindow, PopupWindow, and DockingWindow? What exactly? And what if tommorow MSFT comes up with different mechanism? WHat if tommorow we shouldn't be looking in GAC at all, but instead navigate to some remotely central place? Any answers? If they have a similarly advanced GUI system, then we will be duplicating their work (but I highly doubt that they will). Otherwise, our system should integrate well. What if they will? And what if theres is better?... Or worse, but they have a power of marketing anything they want? And let me tell you -- they do have this power... "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: What if they will? And what if theres is better?... Or worse, but they have a power of marketing anything they want? And let me tell you -- they do have this power... I would hope that with the amount of time that they have had and the amount of money and resources at their disposal, that they really can come up with something better ! However until they let us poor serfs actually see what they are doing its all unknown. We do know that its going to be "managed code" require 3D accelerated hardware and DirectX 9.X Be able to scale controls / windows / the desktop ? and have various lurid flashing color schemes. And reduce the api set from 70k to 8k functions. There is no harm in exploring and designing an alternative ui framework. It will take sometime and if we find out from Microsoft at the Oct PDC that they really do have something even half way decent and a plan to get it wrapped into .NET before the end of time. Then we can drop the project.
-
igor1960 wrote: What if they will? And what if theres is better?... Or worse, but they have a power of marketing anything they want? And let me tell you -- they do have this power... I would hope that with the amount of time that they have had and the amount of money and resources at their disposal, that they really can come up with something better ! However until they let us poor serfs actually see what they are doing its all unknown. We do know that its going to be "managed code" require 3D accelerated hardware and DirectX 9.X Be able to scale controls / windows / the desktop ? and have various lurid flashing color schemes. And reduce the api set from 70k to 8k functions. There is no harm in exploring and designing an alternative ui framework. It will take sometime and if we find out from Microsoft at the Oct PDC that they really do have something even half way decent and a plan to get it wrapped into .NET before the end of time. Then we can drop the project.
There is no harm in exploring and designing an alternative ui framework. It will take sometime and if we find out from Microsoft at the Oct PDC that they really do have something even half way decent and a plan to get it wrapped into .NET before the end of time. Then we can drop the project. I was not trying to stop your project. Go ahead -- do your best to the benefits of yours. I was just trying to share information. I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. Somebody there, please explain to MSFT that normal business cycle in any other industry is much longer the 18 months! "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
There is no harm in exploring and designing an alternative ui framework. It will take sometime and if we find out from Microsoft at the Oct PDC that they really do have something even half way decent and a plan to get it wrapped into .NET before the end of time. Then we can drop the project. I was not trying to stop your project. Go ahead -- do your best to the benefits of yours. I was just trying to share information. I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. Somebody there, please explain to MSFT that normal business cycle in any other industry is much longer the 18 months! "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: I was just trying to share information. Well, thanks. It so happened that it's info that I already knew, but it's nice to have it all gathered in one place. :) igor1960 wrote: I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. I like the changes MS is making in the OS, but I don't like the fact that they are dropping support for C/C++/COM (MFC is something different). I don't see any reason to make these obsolete. WinForms is not modelled in the most efficient way, IMO (although it's pretty good), so if they do something better, I'm happy. igor1960 wrote: Somebody there, please explain to MSFT that normal business cycle in any other industry is much longer the 18 months! Well, do remember that these changes will not take effect for another 2 or 3 years.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
igor1960 wrote: I was just trying to share information. Well, thanks. It so happened that it's info that I already knew, but it's nice to have it all gathered in one place. :) igor1960 wrote: I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. I like the changes MS is making in the OS, but I don't like the fact that they are dropping support for C/C++/COM (MFC is something different). I don't see any reason to make these obsolete. WinForms is not modelled in the most efficient way, IMO (although it's pretty good), so if they do something better, I'm happy. igor1960 wrote: Somebody there, please explain to MSFT that normal business cycle in any other industry is much longer the 18 months! Well, do remember that these changes will not take effect for another 2 or 3 years.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiWell, do remember that these changes will not take effect for another 2 or 3 years. Somehow, I feel that during those 2 or 3 years MSFT will come with something else, that will render obsolete everything that you've managed to develop during that period. May not be even surprised by something like .COM++.:eek: "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
There is no harm in exploring and designing an alternative ui framework. It will take sometime and if we find out from Microsoft at the Oct PDC that they really do have something even half way decent and a plan to get it wrapped into .NET before the end of time. Then we can drop the project. I was not trying to stop your project. Go ahead -- do your best to the benefits of yours. I was just trying to share information. I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. Somebody there, please explain to MSFT that normal business cycle in any other industry is much longer the 18 months! "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: I personally just don't understand MSFT position. For the purpose of making money mostly and just only for themselves, they are putting the whole programming community into the state of dissaray, by rendering current legacy C/C++/MFC/COM as almost obsolete (at least from marketing materials), while at the same time declaring current .NET WinForm as obsolete in 2-3 years from now. I agree 100%. Their behaviour is totally unacceptable and driven purely by a desire to disrupt the market and stall Sun/Java. Whilst there is certainly a case to be made from moving on from a 20+ year old windowing api to something more modern and for a new class framework to supercede MFC. The current .NET Framework isn't it. The .NET Framework is very immature and in many places simply wraps existing windows api's without even an attempt to introduce modern refactored interfaces. Maybe .NET V2 will be the answer but what about all the orphaned .NET V1 code. Its hard to be supportive when you look at the amount of time, money and resources that has been at Microsofts disposal. Then look at what they have managed to deliver and as you so rightly point out, tried to force feed / mass market to us. A good framework wouldn't have needed all this high pressure marketing. It would have been eagerly accepted.
-
Some latest stuff about Longhorn and etc... For those who is planning to write client site WinForm apps/controls -- check it out, yopu maybe waisting time: http://www.3leaf.com/default/articles/ea/Whidbey%20Yukon%20Longhorn%20Pre%20PDC.ppt "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
Could not open your link, but read the other messages, so I think I have the jest of the article. Well, if they make current applications no longer functional on their new OS, then it will be simple, they will have no market. If there is no software, there is no OS. BEOS is a perfect example, object oriented OS with tons of speed and dead except for handhelds. Now, let's say that they do, I would imagine there will be translaters or whatever to make all those .NET applications functional. Since they deal strictly with the .NET library (unless you have been misbehaving) then it is not dependent on the OS but the .NET library. So, you fix the library and all the applications work. Or am I missing the point here somewhere? If I am, then in 2-3 years we can all switch to Linux and run our .NET apps from there ;) Rocky Moore <><
-
Well, do remember that these changes will not take effect for another 2 or 3 years. Somehow, I feel that during those 2 or 3 years MSFT will come with something else, that will render obsolete everything that you've managed to develop during that period. May not be even surprised by something like .COM++.:eek: "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: Somehow, I feel that during those 2 or 3 years MSFT will come with something else, that will render obsolete everything that you've managed to develop during that period. The only thing that would render what we are doing obsolete would be a complete new control library that's at least as good as ours, if not better. I highly doubt they'd do it even in Longhorn, but they certainly will not do it in the interim period before Longhorn is released.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Could not open your link, but read the other messages, so I think I have the jest of the article. Well, if they make current applications no longer functional on their new OS, then it will be simple, they will have no market. If there is no software, there is no OS. BEOS is a perfect example, object oriented OS with tons of speed and dead except for handhelds. Now, let's say that they do, I would imagine there will be translaters or whatever to make all those .NET applications functional. Since they deal strictly with the .NET library (unless you have been misbehaving) then it is not dependent on the OS but the .NET library. So, you fix the library and all the applications work. Or am I missing the point here somewhere? If I am, then in 2-3 years we can all switch to Linux and run our .NET apps from there ;) Rocky Moore <><
Not having backwards compatibility would be the equivalent of shooting themselves in the foot, or maybe even the head. And they know it. What we're talking about now is the issue of how WinForms will not be the latest technology anymore when Longhorn comes out. And what I was saying was that in order for my library to become obsolete, they would have to create a control library on a par with mine, or better. Rocky Moore wrote: Or am I missing the point here somewhere? If I am, then in 2-3 years we can all switch to Linux and run our .NET apps from there :laugh:
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
igor1960 wrote: Somehow, I feel that during those 2 or 3 years MSFT will come with something else, that will render obsolete everything that you've managed to develop during that period. The only thing that would render what we are doing obsolete would be a complete new control library that's at least as good as ours, if not better. I highly doubt they'd do it even in Longhorn, but they certainly will not do it in the interim period before Longhorn is released.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiThe only thing that would render what we are doing obsolete would be a complete new control library that's at least as good as ours, if not better. jdunlap, with all due respect: you are probably very young and therefore extremely optimistic guy. This is very good: I've used to be like that. Now I'm more realistic and maybe that's why much more pessimistic. So, what exactly your new control library is? And why you think it's good? It already exist? Or it's just your "optimistic" design? If your library is so good: shouldn't it be sold then instead of giving it away? That what MSFT does: so you think your free controls can replace possible MSFTs(or others) revenue source? Get real, man... Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
-
The only thing that would render what we are doing obsolete would be a complete new control library that's at least as good as ours, if not better. jdunlap, with all due respect: you are probably very young and therefore extremely optimistic guy. This is very good: I've used to be like that. Now I'm more realistic and maybe that's why much more pessimistic. So, what exactly your new control library is? And why you think it's good? It already exist? Or it's just your "optimistic" design? If your library is so good: shouldn't it be sold then instead of giving it away? That what MSFT does: so you think your free controls can replace possible MSFTs(or others) revenue source? Get real, man... Regards "...Ability to type is not enough to become a Programmer. Unless you type in VB. But then again you have to type really fast..." Me
igor1960 wrote: you are probably very young and therefore extremely optimistic guy. This is very good: I've used to be like that. Now I'm more realistic and maybe that's why much more pessimistic. hmph... igor1960 wrote: So, what exactly your new control library is? And why you think it's good? It already exist? Or it's just your "optimistic" design? That'd be a bit of a long story... Wait 'till you see what comes out of it. :) igor1960 wrote: If your library is so good: shouldn't it be sold then instead of giving it away? That what MSFT does: so you think your free controls can replace possible MSFTs(or others) revenue source? Well, I didn't start out as the leader of this project (even though I was involved in it from the start, and the design is mostly mine), and when it was started, we decided it would be an open-source project. It could make big money, and really I should do it that way, but that wouldn't be fair to the others. I am getting something good out of it, and that is an excellent control library with which I can develop my own applications.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Not having backwards compatibility would be the equivalent of shooting themselves in the foot, or maybe even the head. And they know it. What we're talking about now is the issue of how WinForms will not be the latest technology anymore when Longhorn comes out. And what I was saying was that in order for my library to become obsolete, they would have to create a control library on a par with mine, or better. Rocky Moore wrote: Or am I missing the point here somewhere? If I am, then in 2-3 years we can all switch to Linux and run our .NET apps from there :laugh:
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiOh... That is what I get for guessing at the content of an article that won't come up :) Rocky Moore <><