"Legacy" WinForm .NET Applications
-
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
-
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
-
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
The article is pretty short: " The page cannot be found The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please try the following: * Make sure that the Web site address displayed in the address bar of your browser is spelled and formatted correctly. * If you reached this page by clicking a link, contact the Web site administrator to alert them that the link is incorrectly formatted. * Click the Back button to try another link. HTTP Error 404 - File or directory not found. Internet Information Services (IIS) Technical Information (for support personnel) * Go to Microsoft Product Support Services and perform a title search for the words HTTP and 404. * Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled Web Site Setup, Common Administrative Tasks, and About Custom Error Messages. " You can do it on anything you choose - from .bat to .net - A customer
-
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
Your link, she no work, like unpaid sex-worker. Een Mehico, our links work. http://www.3leaf.com/default/articles.aspx[^] (might be on there somewhere)
Paul Watson
Bluegrass
Cape Town, South AfricaCrikey! ain't life grand?
-
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
I've updated the link: 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
-
The article is pretty short: " The page cannot be found The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please try the following: * Make sure that the Web site address displayed in the address bar of your browser is spelled and formatted correctly. * If you reached this page by clicking a link, contact the Web site administrator to alert them that the link is incorrectly formatted. * Click the Back button to try another link. HTTP Error 404 - File or directory not found. Internet Information Services (IIS) Technical Information (for support personnel) * Go to Microsoft Product Support Services and perform a title search for the words HTTP and 404. * Open IIS Help, which is accessible in IIS Manager (inetmgr), and search for topics titled Web Site Setup, Common Administrative Tasks, and About Custom Error Messages. " You can do it on anything you choose - from .bat to .net - A customer
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
-
'Nuff said.
"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 Gandhihttp://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
-
Your link, she no work, like unpaid sex-worker. Een Mehico, our links work. http://www.3leaf.com/default/articles.aspx[^] (might be on there somewhere)
Paul Watson
Bluegrass
Cape Town, South AfricaCrikey! ain't life grand?
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
-
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
igor1960 wrote: check it out, yopu maybe waisting Why? And yes, I have just read it... - Anders Money talks, but all mine ever says is "Goodbye!" http://SourceLocker.net[^] SourceControl and DefectTracker Project. nsms@spyf.dk <- Spam Collecting ;)
-
igor1960 wrote: check it out, yopu maybe waisting Why? And yes, I have just read it... - Anders Money talks, but all mine ever says is "Goodbye!" http://SourceLocker.net[^] SourceControl and DefectTracker Project. nsms@spyf.dk <- Spam Collecting ;)
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
-
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
I don't think I'll be wasting my time, mainly because most of the controls are lightweight (windowless), and the drawing side of things is separate from everything else, and quite flexible. If I were developing WinForms controls that depended directly on WinForms, that would be different. But since they rely indirectly on WinForms, via an IWindow interface and various window base classes, ony the base classes will need to change in a way that would require re-coding. I hope to support both legacy systems and Longhorn, and only the window classes and a small part of the drawing framework will change for Longhorn.
"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 don't think I'll be wasting my time, mainly because most of the controls are lightweight (windowless), and the drawing side of things is separate from everything else, and quite flexible. If I were developing WinForms controls that depended directly on WinForms, that would be different. But since they rely indirectly on WinForms, via an IWindow interface and various window base classes, ony the base classes will need to change in a way that would require re-coding. I hope to support both legacy systems and Longhorn, and only the window classes and a small part of the drawing framework will change for Longhorn.
"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 Gandhijdunlap, 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
-
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.