Re: Venting on .NET

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below...
On Fri, 06 Jan 2006 12:48:36 GMT, Daniel James <wastebasket@xxxxxxxxxxxxxxxx> wrote:

>In article news:<lrcvf.49392$7h7.4948@xxxxxxxxxxxxxxxxxxxxxxxxxx>, David Ching
>wrote:
>> As I understand it, the the graphical Forms editor in the IDE is more
>> powerful than the dialog editor in VC++. The Forms editor spits out
>> C# code; the Dialog editor spits out a .rc file. So for ease of layout,
>> the tool makes the difference, not so much how it represents the UI
>> (either code or data it makes no difference).
>
>Yes, that's more-or-less how I understand it too.
>
>The problem here is that the Forms editor spits out a mass of C++ code, and in
>that mass of code there is no convenient separation between parts that handle
>the form display (view), the internal representation of the data (model), and
>any manipulations on the data (controller). It's probably easier or the
>tool-writers to write the tool that way, but it makes the resulting code less
>modular and impedes reuse and encapsulation. That may be OK if the code is only
>ever going to be changed using the tools (using C++ as a fancy DDL, I suppose)
>but is far less that ideal if anyone is ever likely to want to edit the code by
>hand.
>
***
Given the incredible poor quality of the user interface of VS.NET, in particular, the
piece-of-crap Properties list, if you make a mistake because of the poor interface (such
as not properly naming a control), hand-editing the generated code to rename a control is
incredibly difficult. Just renaming the control after methods have been generated is not
sufficient. It is clear the person who thought the Properties list could ever make sense
in its current form never once actually wrote a piece of code (example: the most important
sort order is missing: order-of-importance-to-the-programmer, which would put the control
ID and caption as the top two entries. As someone who is a bit more expert on issues of
human cognition than anyone in the .NET development group [I studied under two founders of
the field of cognitive psyhcology, Alan Newell and Herb Simon], I can state that NO design
effort was expended on such irrelevant concepts as user studies, or we would not have the
crap we have).
****
>I have a suspicion that the API was designed hand-in-hand with the tools, and
>that the failure of the API to provide good separation between model, view, and
>controller is largely because the tools didn't require it ... which is kinda
>cheap and shoddy.
****
It wouldn't be so bad if the tools were adequate, but they are not. So what we end up
with is a poor set of tooling coupled with something critically dependent and intertwined
with that poor tooling.
****
>
>> For localization, .NET has an answer with Cultures. ...
>
>Yes, I've read about (but not used) Cultures. They seem to be a reasonable
>approach for internationalization, but are limited to that. That is the most
>common reason for wanting to change resources and keep essentially the same
>codebase, so I suppose they do address the most important issue.
****
I missed cultures, probably due to the lack of good examples. The term does not appear in
either "Inside C#" or "C# Language Specifications". In addition, if I create a control
with a caption, the caption appears in English in the code stream, not as a reference to,
say, a string table entry or other language-insensitive data object. So it is not obvious
that there is any internationalization capability built into C# or its environment. Is
there a good reference on how to use these? (The documention I've found seems to more
sales-oriented that content-containing, explaining how I can get worldwide sales but
tracking down details of how I might convert an existing C# app to be international seems
lacking)
****
>
>> A general comment regarding code vs. resource templates - code provides much
>> greater flexibility in specifying the data.
>
>That's certainly true is we're talking about resource templates in the Win32
>SDK as we know and love them <smile> ... but it doesn't have to be so. A
>resource template from a different resource description language could allow,
>for example, control sizes and positions to be expressed as fractions of the
>size of the parent window. Indeed, it would be a lot easier to program
>resizable dialogs in Win32/MFC if the SDK did allow that.
****
Hand-editing the generated code is usually risky; I would never have considered this an
option, based on how badly previous tooling could cope with hand edits, I remain
suspicious.
****
>
>> I'm not sure the IDE supports the developer editing the generated code to
>> change it as above, but if not, then it could in future versions. But my
>> point is all things are possible in code, whereas data must be hard-coded.
>
>There are always going to be subtleties of layout that (if you use them) will
>require you to tweak things with code -- no resource description language is
>ever going to be perfectly flexible -- but for most cases a resource script
>will be adequate. As you say, though, the ease of use (for the programmer)
>comes down to the support given by GUI design tools, and with good tool support
>the programmer should not need to care whether the design is stored in code or
>data. Either way, though, if you want to tweak the design beyond what the tool
>supports you will have to write code to do it, and either way I think that code
>is going to be simpler to write if the generated code-or-data observes a good
>separation between the view and the model+controller.
****
OnInitDialog handled this well, without requiring editing of the resources. So it is not
clear why hand-editing code is considered "advantageous"
****
>
>Cheers,
> Daniel.
>
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: books for embedded software development
    ... of memory problems, ... hardware which gives control over the CCD functionalities, ... in order not to invest too much time in the "wrong design" and ... the resource requirements of each. ...
    (comp.arch.embedded)
  • Re: Venting on .NET
    ... the Dialog editor spits out a .rc file. ... That's certainly true is we're talking about resource templates in the Win32 ... > I'm not sure the IDE supports the developer editing the generated code to ... comes down to the support given by GUI design tools, ...
    (microsoft.public.vc.mfc)
  • CORCS09 - Call for papers
    ... and practical aspects of component based design of such systems. ... Any submission whose content is relevant to the area of resource ... Papers must be submitted electronically via the CORCS 2009 Submission Page. ...
    (comp.specification.z)
  • CORCS09 - Call for papers - Extended submission
    ... and practical aspects of component based design of such systems. ... Any submission whose content is relevant to the area of resource ... Papers must be submitted electronically via the CORCS 2009 Submission ...
    (comp.specification.z)
  • Re: Resource Levleing Calculations
    ... For each Drawing, we: ... Design (with the resource). ... Production Operations Build schedule. ...
    (microsoft.public.project)