how the other half lives
-
I've had a few small projects requiring VC++ and I've dabbled a lot with MFC/ATL/WTL, but far and away I am a VB dev. As I don't know any VC devs, I've always been curious about what real VC devs do for work and how they get it done (tools, technologies, methodologies, etc...). I'm also curious to know if any VC devs are doing the kind of development I do with VB, namely a complex business application with a database backend. VB seems ideally suited to this project for many reasons. For example, we have a high number of data entry forms (100+) which are implemented as user controls in separate modules, then dynamically loaded onto a host form at runtime. The host form contains the toolbar and a couple other interface elements. It communicates with the user control through one or more interfaces. The host form will enable and disable certain interface elements depending on what interfaces the user control supports. How would a VC dev manage this complexity? Finally, I've been spending a lot of time with C#/.NET ever since the first NGWS SDK became available. Unlike the doc/view architecture, message maps, subclassing, etc..., the development model seems entirely familiar to me. This makes me wonder how VC devs are taking to it. Does it seem like a large change from the way things get done in VC? Regards, Dan
-
I've had a few small projects requiring VC++ and I've dabbled a lot with MFC/ATL/WTL, but far and away I am a VB dev. As I don't know any VC devs, I've always been curious about what real VC devs do for work and how they get it done (tools, technologies, methodologies, etc...). I'm also curious to know if any VC devs are doing the kind of development I do with VB, namely a complex business application with a database backend. VB seems ideally suited to this project for many reasons. For example, we have a high number of data entry forms (100+) which are implemented as user controls in separate modules, then dynamically loaded onto a host form at runtime. The host form contains the toolbar and a couple other interface elements. It communicates with the user control through one or more interfaces. The host form will enable and disable certain interface elements depending on what interfaces the user control supports. How would a VC dev manage this complexity? Finally, I've been spending a lot of time with C#/.NET ever since the first NGWS SDK became available. Unlike the doc/view architecture, message maps, subclassing, etc..., the development model seems entirely familiar to me. This makes me wonder how VC devs are taking to it. Does it seem like a large change from the way things get done in VC? Regards, Dan
Daniel Pratt wrote: curious about what real VC devs do for work I've used VC++ to build imaging SDKs, numerous desktop apps and an expert system infrastructure. Daniel Pratt wrote: The host form will enable and disable certain interface elements depending on what interfaces the user control supports. How would a VC dev manage this complexity? It's pretty easy to build GUIs using VC++. In a past life, I wrote the GUI for a Photoshop export module for a souped up dye-sub printer that had a large # of options. The GUI's controls has numerous dependencies (kept in synch using a Moderator design pattern) and various funky GUI-isms, including flashing tabs. It was pretty easy to do. /ravi "There is always one more bug..." http://www.ravib.com ravib@ravib.com
-
I've had a few small projects requiring VC++ and I've dabbled a lot with MFC/ATL/WTL, but far and away I am a VB dev. As I don't know any VC devs, I've always been curious about what real VC devs do for work and how they get it done (tools, technologies, methodologies, etc...). I'm also curious to know if any VC devs are doing the kind of development I do with VB, namely a complex business application with a database backend. VB seems ideally suited to this project for many reasons. For example, we have a high number of data entry forms (100+) which are implemented as user controls in separate modules, then dynamically loaded onto a host form at runtime. The host form contains the toolbar and a couple other interface elements. It communicates with the user control through one or more interfaces. The host form will enable and disable certain interface elements depending on what interfaces the user control supports. How would a VC dev manage this complexity? Finally, I've been spending a lot of time with C#/.NET ever since the first NGWS SDK became available. Unlike the doc/view architecture, message maps, subclassing, etc..., the development model seems entirely familiar to me. This makes me wonder how VC devs are taking to it. Does it seem like a large change from the way things get done in VC? Regards, Dan
Daniel Pratt wrote: high number of data entry forms (100+) I already did this using VC++ and MFC, with a slight twist, if 50 windows were open at the same time, all the variables modified on one window thad had dependencies on the other windows , automatically updated the content on all the related windows. Daniel Pratt wrote: the development model seems entirely familiar to me Quite true, i used to program in VB on my first programming job, and of course it's very easy to a vb programmer to jump to .NET , or at least to the visual way of programming. Cheers, Joao Vaz
-
I've had a few small projects requiring VC++ and I've dabbled a lot with MFC/ATL/WTL, but far and away I am a VB dev. As I don't know any VC devs, I've always been curious about what real VC devs do for work and how they get it done (tools, technologies, methodologies, etc...). I'm also curious to know if any VC devs are doing the kind of development I do with VB, namely a complex business application with a database backend. VB seems ideally suited to this project for many reasons. For example, we have a high number of data entry forms (100+) which are implemented as user controls in separate modules, then dynamically loaded onto a host form at runtime. The host form contains the toolbar and a couple other interface elements. It communicates with the user control through one or more interfaces. The host form will enable and disable certain interface elements depending on what interfaces the user control supports. How would a VC dev manage this complexity? Finally, I've been spending a lot of time with C#/.NET ever since the first NGWS SDK became available. Unlike the doc/view architecture, message maps, subclassing, etc..., the development model seems entirely familiar to me. This makes me wonder how VC devs are taking to it. Does it seem like a large change from the way things get done in VC? Regards, Dan
Daniel Pratt wrote: How would a VC dev manage this complexity? Just like VB dev. I mean, VB is not the only tool for implementing modules communicating between themselves via interfaces. C++ gives you much more degrees of freedom in implementaion, but 10,000 feet view would be more or less identical. Tomasz Sowinski -- http://www.shooltz.com
-
Daniel Pratt wrote: How would a VC dev manage this complexity? Just like VB dev. I mean, VB is not the only tool for implementing modules communicating between themselves via interfaces. C++ gives you much more degrees of freedom in implementaion, but 10,000 feet view would be more or less identical. Tomasz Sowinski -- http://www.shooltz.com
First, thanks to you and the other posters for your responses :) Tomasz Sowinski wrote: Just like VB dev. I mean, VB is not the only tool for implementing modules communicating between themselves via interfaces. Of course, I didn't mean to suggest otherwise. Tomasz Sowinski wrote: C++ gives you much more degrees of freedom in implementaion... I agree. Of course this makes the decision of how to implement much harder :) Tomasz Sowinski wrote: ...but 10,000 feet view would be more or less identical. I was more interested in what the view looks like from 1,000 feet. I mean, would you use MFC extension DLLs containing doc/view classes, or ATL components or something else? I am fairly knowledgeable of the capabilities of VC++, however I have a weak knowledge of what is practical in terms of scalability, maintainability, etc., stemming from a lack of experience. Regards, Dan
-
First, thanks to you and the other posters for your responses :) Tomasz Sowinski wrote: Just like VB dev. I mean, VB is not the only tool for implementing modules communicating between themselves via interfaces. Of course, I didn't mean to suggest otherwise. Tomasz Sowinski wrote: C++ gives you much more degrees of freedom in implementaion... I agree. Of course this makes the decision of how to implement much harder :) Tomasz Sowinski wrote: ...but 10,000 feet view would be more or less identical. I was more interested in what the view looks like from 1,000 feet. I mean, would you use MFC extension DLLs containing doc/view classes, or ATL components or something else? I am fairly knowledgeable of the capabilities of VC++, however I have a weak knowledge of what is practical in terms of scalability, maintainability, etc., stemming from a lack of experience. Regards, Dan
Daniel Pratt wrote: Of course this makes the decision of how to implement much harder I'd say that it requires more experience. Once you have it, it's not that hard. Daniel Pratt wrote: I was more interested in what the view looks like from 1,000 feet. Yes, I'd use extension DLLs and doc/view - assuming that forms are for use in this app only. Otherwise, COM would be the only logical choice. Daniel Pratt wrote: I have a weak knowledge of what is practical in terms of scalability, maintainability, etc., Scalability is where C++ really shines. With common code in base classes and/or templates you're free from copy-paste style of reuse, frequently seen in VB projects. Maintanability - well, it requires skilled programmers, generally they cost more than VBers. Tomasz Sowinski -- http://www.shooltz.com
-
Daniel Pratt wrote: Of course this makes the decision of how to implement much harder I'd say that it requires more experience. Once you have it, it's not that hard. Daniel Pratt wrote: I was more interested in what the view looks like from 1,000 feet. Yes, I'd use extension DLLs and doc/view - assuming that forms are for use in this app only. Otherwise, COM would be the only logical choice. Daniel Pratt wrote: I have a weak knowledge of what is practical in terms of scalability, maintainability, etc., Scalability is where C++ really shines. With common code in base classes and/or templates you're free from copy-paste style of reuse, frequently seen in VB projects. Maintanability - well, it requires skilled programmers, generally they cost more than VBers. Tomasz Sowinski -- http://www.shooltz.com
-
Daniel Pratt wrote: Of course this makes the decision of how to implement much harder I'd say that it requires more experience. Once you have it, it's not that hard. Daniel Pratt wrote: I was more interested in what the view looks like from 1,000 feet. Yes, I'd use extension DLLs and doc/view - assuming that forms are for use in this app only. Otherwise, COM would be the only logical choice. Daniel Pratt wrote: I have a weak knowledge of what is practical in terms of scalability, maintainability, etc., Scalability is where C++ really shines. With common code in base classes and/or templates you're free from copy-paste style of reuse, frequently seen in VB projects. Maintanability - well, it requires skilled programmers, generally they cost more than VBers. Tomasz Sowinski -- http://www.shooltz.com
Tomasz Sowinski wrote: Scalability is where C++ really shines. With common code in base classes and/or templates you're free from copy-paste style of reuse, frequently seen in VB projects. Our current architecture keeps the cutting and pasting to an absolute minimum, but it is not always easy and it is not always possible. I'm chomping at the bit to be able to implement our application in .NET, in large part so we can take advantage of inheritance. Tomasz Sowinski wrote: Maintanability - well, it requires skilled programmers, generally they cost more than VBers. Okay, now it sounds like you're referring to skilled programmers and VBers as mutually exclusive groups, but perhaps I'm being sensitive ;) I'll just assume you mean skilled VC programmers v.s. skilled VB programmers :) Regards, Dan
-
Tomasz Sowinski wrote: Scalability is where C++ really shines. With common code in base classes and/or templates you're free from copy-paste style of reuse, frequently seen in VB projects. Our current architecture keeps the cutting and pasting to an absolute minimum, but it is not always easy and it is not always possible. I'm chomping at the bit to be able to implement our application in .NET, in large part so we can take advantage of inheritance. Tomasz Sowinski wrote: Maintanability - well, it requires skilled programmers, generally they cost more than VBers. Okay, now it sounds like you're referring to skilled programmers and VBers as mutually exclusive groups, but perhaps I'm being sensitive ;) I'll just assume you mean skilled VC programmers v.s. skilled VB programmers :) Regards, Dan
Daniel Pratt wrote: I'll just assume you mean skilled VC programmers v.s. skilled VB programmers Yes :-D Tomasz Sowinski -- http://www.shooltz.com