What annoys you about VS.NET 2003 IDE & CF?

  • Thread starter Thread starter Saul
  • Start date Start date
S

Saul

Hi all,

I have been developing in VS.NET 2003 with the Compact Framework for a
little while now, and I have list of pet peeves that I *need* to share (for
my own wellbeing, you know, it's like and itch you can't scratch). Of
course, some of you may have other gripes. Feel free to add them to this
list. You will feel better! And maybe, just maybe, someone who can do
something about this will listen.

1. VS.NET 2003 Updates/Service Packs. My gripe here is that there don't seem
to be any (yet). There are plenty of bugs with this app, so where are the
service packs? Surely the answer to this isn't "buy VS.NET 2005 when it's
released"?

2. Windows changes are slow and clunky, even on a fast machine. What I mean
by that is window navigation, such as getting help or using the "autohide"
features. The whole thing sometimes pauses for a few seconds. I need to
"auto hide" things because even on a 17" monitor there are screen areas at
the top, left, right and bottom. Without the autohide you only have a small
area in the middle for your code! Also, sometimes you need to click on the
window tab to activate it, and other times just hovering over it activates
it. Sometimes I hover when I should click, which makes me feel like a fool.
Also, similarly, I find the "open documents" list at the top of the screen
re-orders itself, which is not helpful. The side scrolling quickly becomes
useless if you have a lot of files open.

3. Properties. What I really miss is a section called "events" with all the
event types in it for an object, like you have in Access. This is a huge
thing for me, and I was really surprised that this was not there. Also,
there are a lot of properties, it seems, missing that you can only set in
code. Why this is I am not sure, they should all be there. As the compact
framework only supports limited things, ideally only those properties/events
should be shown when developing an application in it. This avoids you
programming to an event that is never called.

4. Bugs! The worst one I find I hit often is the forms lose the ability to
be edited by the forms designer. The workaround is to edit the code and
"retype" the ".form" on the end of the command "Inherits
System.Windows.Forms.Form" or add a new form to the project. But this is
just stupid, c'mon. Others include randome re-ordering of tabs in the tab
control. Sometimes when I close/reopen a project it claims it can't write to
the projectname.vbdproj.user file, which is odd. These bugs seem quite
obvious for someone who has only used the software for a shart time and
really should never have gotten past QA. See item #1.

They are probably the worst problems, although I have hit some specific
irritating things with the CF (eg Treeview control not allowing you to open
a form from the AfterSelect event. Well, it let's you open it but you can't
get it to come to the front).

So, do you agree with some of mine? Do you have some of your own burning you
up?? ;-)

Regards,
Saul
 
Hi Saul, I work with the Visual Studio for Devices team and we are not
only listening to your feedback, we are also constantly trying to give
better product based on feedback we receive from our customers.

1. we are working on fixing some of the issues mentioned below in a
Service Pack currently. At this point I don't have an ETA on when
these would be released.

2. Do you only see the slowness when building Smart Device projects or
do you experience this will other projects as well ?

3. Properties. If you create a VB project then you can see all the
events listed in the dropdown in the code editor. For C# on the
property grid there is a button for Events (looks like a lighting
bolt). Is this what you are looking for ?

Compact Fx only support a subset of the events / properties compared
to the desktop Fx.

Filtering event/methods has known issue as you rightly identified,
however a clean fix for this will only show up in the next release.

4. Bugs: (Losing the form) I will review this issue to see if there is
something we can do in upcoming service release to address this.

I will also pass feedback on the other issue to the respective teams
to evaluate accordingly.

Thanks for your feedback.

Amit Chopra
 
1. Yes, I'd like to see a service pack as well. Dynamic Button events seem not to work in VS.NET 2K3.

2. To speed up autohide: Tools|Options|General. There's a slider called "Animate environment tools" - slide it all the way to "+", then autohide is pretty much instantaneous. For more fun, slide it all the way to "-" and see how slow it hides.

3. Events are listed for controls with events: In the Properties window, if there are events to be displayed, click the 'lightning bolt' icon (Right at the top) to see them.

4. Haven't run into any of them, sorry.
 
Amit,

*Stunned*

Cool! Thanks for all that!! One of the reasons we dumped Palm development is
because of the support and resources in the PocketPC world. Your reply
reinforces my opinion in this regard.

On this point --
3. Properties. If you create a VB project then you can see all the
events listed in the dropdown in the code editor. For C# on the
property grid there is a button for Events (looks like a lighting
bolt). Is this what you are looking for ?
Click to expand...

Yes, sounds like it. This should be in the properties page when editing a
form in the form editor, so that you can create code easily and quickly from
there. I use VB, so I was not aware of the C# event button, but it sounds
like the right kind of thing. I was already aware of the dropdown in the
code editor (and use it), this is really what should be in the properties
tab.

Ideally, and this is just an idea, you should also be able to "go backwards"
from the code back to the form editor. That is, say, on a button_click event
procedure, right click and choose "Edit in form Editor" or something to that
effect, which opens the form editor and selects the button.

This tighter integration of the form editor/code would help speed up
development quite a bit I think. I have lots of forms in my apps, and I
spend quite a bit of time going between the code and form editor.

Thanks again,
Saul

ps. If anyone else still has some other issues with the IDE, let's hear 'em!
 
SSP said:
Random re-ordering of the tabs
I still can't get over it.

SSP
Click to expand...

Yep. I second that one. Before building for release, I ALWAYS double check
every tab control in the app to make sure they are order correctly because
they seem to play "musical tabs" in the middle of the night some how...

doogman
 
The workaround for me is to not use the designer mode.
Everytime I do so, it reorders the tabs. I then have to edit the code behind
to get it right.

SSP
 
I have problems with bookmarks and navigate buttons...
I use vs.net 2003 pro eng, c#.
The bookmarks only work inside the same .cs, don't seem to work globally
(e.g: bookmark the call to a function, go see the function code, press the
goto bookmark leads to the call only if it's in the same .cs)
And the navigate buttons rarely take you to the places you've really been.

This is really annoying.

Regards,
Matteo Cima,
Senior Developer, Mobile Expert, Project Manager, Lead Analyst,
Dotnet, C# (Csharp) and Compact Framework Expert
Digisoft srl Italy
msn: matteodellamontagna_hotmail_com (you know what to do with those
underscores, don't you?)
 
Here's my list:

1. Visual Studio should implement a "local assembly cache" (lac) in place of
<vstudio>\CompactFrameworkSDK\v1.0.5000\Windows CE and ...\Windows
CE\SmartPhone to allow multiple cultures and versions of third party
assemblies. It's dumb to have all the versioning and localization features
of assemblies ignored by VS.

2. Visual Studio should allow designer DLLs to be either in a "local
assembly cache" under the ...\Windows CE\Designer folder, or have a
different name than the device assembly (see also item 3).

3. When a custom component is drag onto the designer, and that component has
a designer dll, Visual Studio should add the references of the corresponding
device assembly and its dependencies - NOT the dependencies of the designer
dll. For example if the designer makes use of envdte to select defaults
based on project settings, Visual Studio should not be downloading envdte to
the device.

4. Visual Studio should have the ability to pick up the appropriate native
dll for the specified target (arm vs. x86 vs. mips) so that a user can
seamlessly switch from emulator to device without removing and re-adding the
native dll to the project. Such native dlls should probably be linked to the
managed assembly in a version safe manner (i.e. assembly A v1.0 links to dll
B v 1.0, A v1.1 links to dll B v1.1).

5. Help text for components that appears in the properties window should be
taken from the corresponding assembly.xml file, not using the Description
attribute. This allows for proper translation of the text. The
System.ComponentModel.DescriptionAttribute isn't even supported under the
compact framework at the moment.

Thanks,

Philippe
 
Hi Philippe, Matteo , I am reviewing your feedback and sharing with my
team. I will respond back when I have more details on if we are
planning to address some of these issue.

and thanks Chris for helping with options and workarounds.

Amit Chopra
 
Philippe,

Although I don't have any solutions for you with the Visual Studio 2003 release, there are elements of the Visual Studio 2005 "whidbey" release that we are working that I think may address the problems that you've identified.

1. There are some alternate options/scenarios here that you might be addressing, so feel free to clarify the problem for me if I answer a different question than you were asking. To restate the question, the issue is that the managed SDK directory for Smart Device projects is limited to a single directory...this single directory cannot, as a Win32 file system, handle servicing releases, etc of a given file (i.e. filename is all that defines a file, so a subsequent version would have to be renamed to also be installed to this location). As a consequence, you are forced to choose a particular version or perform some manual steps to switch back-and-forth.

In the Visual Studio 2005 Whidbey release, this problem will be addressed by a registration mechanism under the appropriate .Net Framework registry key (in this case, the .Net Compact Framework). This will allow you/the IDE to clearly identify what assemblies are pertinent for a given device platform and device runtime combination. You can see this mechanism in the Whidbey preview release from VS Live and subsequent Community Drops as well as in the upcoming Beta release. If you need any pointers to get access to any of these, Amit (on this thread earlier) can help you get set up.

This registration mechanism is primarily of interest to Control/Component vendors and Platform SDK vendors, both of whom would have developer SDK's that are installed on top of a Visual Studio install. If you fall into that camp, let me or Amit know and we can try to provide additional details.

------

2. The WinForms designer infrastructure has changed substantially for device projects. Recompiled "design-time" versions of controls will no longer be necessary and WinForms integration/support will be simplified (although not free for anything beyond simple, managed only controls).

In their place, Control/Component vendors provide metadata assemblies that have no implementation, but contain the attributing (Designer, Editor, DefaultValue, etc.) that you lost when you compiled the real run-time assembly for the device.

------

3. As a consequence of the above two changes, only a true run-time reference will be added to your project.

------

4. Can you expand on this scenario? Is this for a solution with mixed native and managed development? Or is this a solution that has a managed project that references a "random" device binary (e.g. one that does not have any developer install or deployment CAB for installing the appropriate bits on a device)? Or perhaps this is a project using PInvoke?

------

5. We're actively working on ensuring that the metadata mechanism I mentioned above can provide for and handle localized property descriptors, etc.

Thanks for taking the time to provide this feedback and let us know if you think these will address your concerns.

--
Jason Smith
Development Lead
Visual Studio for Devices Team

This posting is provided "AS IS" with no warranties, and confers no rights.
 
1. Our product is for developers and includes localized resources for a
managed assembly. We would like our customers to have the option of having
two different version of our product installed (while migrating). We expect
our customers to have the "standard" version of VStudio.

Jason Smith said:
4. Can you expand on this scenario? Is this for a solution with mixed
Click to expand...
native and managed development? Or is this a solution that has a managed
project that references a "random" device binary (e.g. one that does not
have any developer install or deployment CAB for installing the appropriate
bits on a device)? Or perhaps this is a project using PInvoke?
Our product includes a managed dll, un-managed dlls for various
architectures (arm, armv4t, mips, x86) and managed resource dlls (en, fr,
de, ...). The managed dll uses PInvoke. What we want is that when the user
adds the managed dll to their project, they get the resource dll and
appropriate unmanaged dlls so when they tell VStudio to deploy to the
emulator, VStudio ensures that all those dlls are copied over and if they
change from the emulator to a real device, VStudio knows that it needs to
copy a different un-managed dll.
Thanks for taking the time to provide this feedback and let us know if you
Click to expand...
think these will address your concerns.Thanks for addressing these concerns,
Philippe
 
Jason Smith said:
1a. How or for what do you use the localized resources at design-time in
Click to expand...
the IDE? I'll follow up with the specific developers and ensure that we're
doing the right things here.The localized resources are for the user to add to their project so that
they are copied to the device at deployment time.

Philippe
 
How about not being able to view two different source files
simultaneously side-by-side? (unless I'm missing something).
Thanks, Mark
 
You can surely do that. Go to the Windows menu and choose New Horizontal
Tab Group or New Vertical Tab Group.

Paul T.
 
What annoys me about VC++ .NET in particular but is not limited to that IDE is the fact that importing projects from version 6 or earlier of Visual C++ or the other Visual Tools, will not compile correctly. For instance if I take a Visual C++ 6 project I have created, and then compile it, I am already guaranteed one error even though I said yes to convert the project to a VC++ .NET 2003 solution. The error that will almost always occur is the infamous 3dControls error. Microsoft should make IDEs that when you open older project files, it will convert seamlessly, so that the developer doesn't have to manually remove the code. Also there is NO and I mean it NO delete variable option in the class view. So if I have a variable that I wish to delete, how do I have to delete it? You got it, manually remove it from the code. And if this is a control variable, I have to look through numerous parts of my code to remove the references to DDX and other things added in when a control variable has been created. There are so many others, take a look at Bob Moore's (he is a Microsoft MVP for Visual C++). He has a opinion article on the IDE, the link to the article is
http://bobmoore.mvps.org/opinion/opinion004_VSNet.htm
That will give you alot of the bugs and other garbage that us Visual C++ developers had to face when developing apps in this IDE.

Sincerely,

James Simpson
 
- Word wrap in the editor is virtually useless. When enabled, it turns the
display of the code into an unintelligible mess, carat and selection behavior
is not at all correct, etc. *Very* poorly defined.

- No intrinsic way to switch between .h and .cpp source files.

- No keyboard command for "open selection" as was available in previous
versions.

- No way to create virtual folders in C# projects as can be done in C++
projects.

- No way to manage the start page recent projects.

- Toolbox panes have non-standard slide-effect when switching between tabs;
doesn't respond to system user display effects.

- Toolbox contents to not respond to mouse wheel scroll.

- Open window tabs do no respond to horizontal mouse scroll.

- Open window tabs very subject to clutter.

- Open window tabs a real pain to navigate when width extends past edge of
frame (i.e. scrolling).

- No ability to configure open window tabs to allow for multiple rows rather
than scrolling.

- Open window tabs: in short, take a note from WndTabs -- a nice
implementation, done right.

- Virtual space, when enabled, doesn't behave correctly at the end of the file
-- it should allow positioning past the *end* of the file, as was the case in
previous versions.

- There should be some customization of the various code completion, etc.
popup windows, such as placement (how close to the insertion point,
transparency, above/below, etc.) so that it doesn't necessary block context on
the prior or subsequent line(s).

How's that for a start...
 
how about something really simple?

like being able to close a split by dragging the divider bar up OR down
(instead of just up as it currently works)

i mean come on, old versions of visual studio had this feature . . .
 
Back
Top