dcsimg
Results 1 to 31 of 31
  1. #1

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Using an old version of .Designer File?

    I have a VB.Net Windows app in which I have a Form that somehow when I run the app, the Form looks as it should, but in design mode, some of the controls are out of place, not aligned like it looks when it's running. I don't know how to fix this because I don't know what caused it. But....I was wondering if I could take an older version of the .Designer file (when it looked correct in design mode) and pull it from TFS into the current code. Is this possible?

    Thanks
    Blake

  2. #2
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    It should be possible. There's nothing magic about those .designer files. They don't even need to exist, really. All you have in there is a partial class for the form. If you took the exact same code and put it into the .vb file for the form it will work just as well. I've got an application like that. Everything you find in the .designer.vb file is found in a region in the main form. All .NET forms worked like that up until partial classes were introduced in the 2005 version. The way to think about it is that the .designer file is combined with the .vb file at the compilation stage. They are only separated for organizational purposes. So, yeah, there shouldn't be an issue using one over the other. Heck, even the designer doesn't care whether the code is found in the .designer file or not.
    My usual boring signature: Nothing

  3. #3

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Thanks Shaggy...I might give this a try!
    Blake

  4. #4

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Unfortunately pulling in an older version of the .designer file did not work. I have attached screenshots that show the Windows form in Design Mode as well as Execution Mode. You can see the difference clearly and again, I have know idea why it's doing that.
    Blake

  5. #5
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    Well, the older version will have whatever settings were in place for the older version. The only differences I see between the two images appear cosmetic. Things like the font, text, one color, and a few other things. Basically, the older one is older. All of the differences can be seen from examining the code....though there's likely a LOT of code for those two forms. For each control, you will see near the top where the control is declared, then further down in InitializeComponents you will find a block where all the settings you set in the designer are applied to properties of each control. The differences between the two files will be largely in the values assigned to those properties. There will also likely be some controls that are different, as I see something along the left edge which looks like a tiny label, but which is missing entirely from the other form.

    So, it worked, there were just more differences between the two designer files than you had expected. You get to decide whether you want to change the old one to look more like the new, or change the new itself.
    My usual boring signature: Nothing

  6. #6
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,580

    Re: Using an old version of .Designer File?

    Shaggy, I think what he means is:

    One screenshot represents the form as it is represented on the Designer. The other screenshot represents what appears on-screen if he builds and runs the project.

    Still, some of what you said applies, I think? It seems like this project needs a "build clean", then a "rebuild all". That might not even be enough. The sequence I'd try is "build clean", "close Visual Studio", "delete **/bin and **/obj", then "rebuild all". It's possible that, somehow, the designer is loading things that are artifacts from building the "newer" designer file, but at runtime you get what came from the "old" designer file. Because it does make sense there would be differences between new and old.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  7. #7

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Sitten,

    I did what you suggested and unfortunately it did not work.

    I tried a test where I displayed the Forms Width/Height properties when I rebuilt and executed the app. Both of those properties were the same values as was in the designer, even though the dimensions and certain controls looked off.

    Another I noticed that when I make a change to a control or add a new control, the form renders as it looks in Design mode (messed up). Consequently, I can't even make design changes to the Form(s).
    Blake

  8. #8
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    Ah, well, I'd say that something is getting stored elsewhere, in that case...though there is a third possibility.

    As I said before, the designer file isn't magic. You could copy that code into the form and delete the .designer.vb file. It would make no difference. It wouldn't help you any, it wouldn't hurt you any (as long a you did it right). That file is just code and code that you could write on your own. Heck, I often add a constructor for my forms, at which point the constructor is removed from the .designer.vb file. The only reason people don't edit the .designer.vb file is that the designer may come in and wipe out your changes...or not. You can't move things around safely, but you can generally add and alter things.

    The point of that is that the .designer.vb file doesn't have any hidden magic. It declared a bunch of objects (all the controls on the form), it sets properties for those objects, it adds those objects to various Controls collections, and that's all it is doing. So, the problems you are seeing lie elsewhere.

    One thing I have seen is a mechanism that stores layout information during startup or shutdown. That wouldn't happen by accident. Somebody wrote it, in the case I saw, but since it wasn't ME that wrote it, what it was actually doing was a bit opaque. It was in the Resize event. Only you'd know whether that could even be a possibility (if you wrote it all, then it could only happen if you've forgotten what you wrote). Also, you can note that Windows will retain certain state for some things. This rarely impacts programs, and doesn't seem to be the case here.

    The other thing that comes to mind is DPI settings, which can alter layout on hi-res displays.
    My usual boring signature: Nothing

  9. #9

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Shaggy,

    I'm trying to move all the .Designer code into my Form code and I'm getting a design-time error, which I have attached. The Designer code is a Partial Class of the Form. The Forms name is "frmCalibration_3", which the class name defaults to. Since I have never done this before, what exactly should I copy and what should I leave behind in the .Designer file?

    Thanks
    Blake

  10. #10
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,580

    Re: Using an old version of .Designer File?

    The nature of the changes I'm seeing don't seem like what I'd normally expect from DPI, the usual suspect.

    The most probable cause is you have some code that runs based on some event that changes the layout. The reflex is to respond with, "No I don't", but humor me for a minute. Comment out everything but the class definition in the not-Designer file and see what happens.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  11. #11

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    When you say "not-Designer" file, I'm assuming the Forms code-behind code? The files are

    frmCalibration_3.vb
    frmCalibration_3.Designer.vb
    frmCalibration_3.resx


    By the way, is the .resx file needed?
    Blake

  12. #12
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    I was saying that you CAN move all the data from the .designer.vb file, not that you SHOULD. I believe that if you put it into the form code then you need to have it in a certain Region with some specific strings, or else the designer won't work anymore. I've never paid much attention to that, other than to note that I have a program where that's the case. I haven't studied that to see whether or not the wording on the region is what is important, or even if it is the wording (or the region itself) that is important. It's just not worth doing.

    If you are doing this because you think the .designer.vb file is the problem, then don't bother. The file itself is nothing more than a text file. There's nothing special about it other than the name. You could open it in Notepad. Furthermore, the code in it is just code. There's no hidden stuff and no magic. If we figure out how to copy the .designer code over to the form (I could look up the region), all that would show is that there is no magic. It would work exactly the same way it is working now, because there's nothing else. Don't be blaming the .designer.vb file. You may blame the code in it, but that's just code. Otherwise, the file just has that .designer. tag so that the IDE knows that it can safely re-write anything in that file at any time. The Region, or whatever identifier is used, in the main form would do the exact same thing. It just lets the IDE know that it's safe to make changes to that block of code. Any problems are in the code itself, where it's located has no impact.
    My usual boring signature: Nothing

  13. #13

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Well, with all that said, I'm still at a loss as to how to fix this. It just doesn't make any sense. The Form code does not do any resizing at all, when the app is run the Form looks correct, which is what it use to look like in design mode.
    Blake

  14. #14
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    Yeah, having re-read your initial question, I'm at a loss, too. While there's no hidden magic in the .designer.vb file, there sure is some in how the IDE sets up the display. I have one form that simply won't show in the designer anymore, though it works perfectly. In that case, I kind of know what did it, and I don't really need the designer for anything, so I haven't bothered looking at it.

    Another way you can mess with the designer is to move the definition of one form into the definition of a different form. There's nothing technically wrong with this, because you can always define one class within another (though you generally don't want to), but doing that sure messes with the designer.

    There's something going wrong with how the designer sets itself up based on the contents of the files, but I've never seen what you described, so I don't think I have anything more worth suggesting.
    My usual boring signature: Nothing

  15. #15

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    If I sent you the .Designer file, would that help you get an understanding?
    Blake

  16. #16
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,580

    Re: Using an old version of .Designer File?

    The most logical explanation is you have code/event handlers that change the form's layout at runtime. I'm not saying that's 100% the problem, as Shaggy Hiker is right and sometimes the designer does dumb things.

    I think if you could post the designer file AND the main form file we could at least figure out if that's the case. Having one without the other doesn't help as much as having both.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  17. #17
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    Which version of VS are you using?
    My usual boring signature: Nothing

  18. #18

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Here are both of the files...thanks for your help!
    Blake

  19. #19

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    I'm using VS 2015 Enterprise edition.
    Blake

  20. #20
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    31,623

    Re: Using an old version of .Designer File?

    Ok, so if I'm following correctly, at run-time, the form looks OK. At design-time it doesn't. BUT if you then make a change the the form, it no longer looks fine at run-time, and looks jacked, just like it did in the IDE at design time. Hmmm... what about IDE plugins? are there any plugins or addins you've got in the IDE?

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  21. #21
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    I don't have 2015 available on this system. It may not matter much, as a designer file wouldn't care, but it's not much of a test to create a new form in 2010 and use that designer file. It likely wouldn't show anything. I may not be able to try it until Friday, though I might be able to try it in 2017 later on today. I don't have 2015 installed anywhere anymore.

    That's always a possibility, too. 2015 had a fair few bugs to it.
    My usual boring signature: Nothing

  22. #22

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    I did remove a couple of obvious plug-ins. We're waiting to get 2017. Hopefully that will clear up this issue.
    Blake

  23. #23
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    4,447

    Re: Using an old version of .Designer File?

    I don't know if 2017 will fix things or not.
    You didn't say what operating system you're using.

    I know at some point with a Win10 version update, the size of things and what they look like in the IDE do not match what the form looks like when run.
    And that is with the DPI setting set for 100%. Setting it to 125% still looks different between the IDE and when it is run.
    In my case, since it hasn't cause a problem, just doesn't look the same, I only played around a bit to see if I could straighten it out, and tried some searches on the issue, but it seems like it may be a recent phenomenon and I gave up trying to find a solution for now.

  24. #24

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    I did forget to mention it but I am using Windows 10. I currently have my DPI set to 125%. When I toggled back and forth, I didn't reboot my machine. Not sure if that matters or not though.
    Blake

  25. #25
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    I tried looking at the file, but it didn't show anything, nor would I expect it to. You are using a few 3rd party components that I don't have. The only way I could get it to compile was to comment out everything that made use of the DevEx and SenseIt components, which would take a fair amount of stuff of the form. Anything I saw at that point wouldn't prove anything anyways.
    My usual boring signature: Nothing

  26. #26

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    The SENSIT Components are all UserControls built specifically for this app. The DevExpress components are for reporting purposes (like Crystal Reports).

    Thanks for looking Shaggy!
    Blake

  27. #27
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,580

    Re: Using an old version of .Designer File?

    I have a lot of comments to make but almost none of them seem like they'd lead to this particular problem save one.

    A 14,000 line Form file is no longer a Form file. It's "your entire program" crammed into one file. You'd benefit greatly from learning how to use helper methods to implement the "don't repeat yourself" principle and, from there, learning how to extract helper methods to helper classes. This 14,000 line form should probably be, at best, 2,000-4,000 lines of code (with the other 10k spread across at least 10-15 helper classes.)

    The size of the form makes it hard for me to definitively say I chased every event that should be raised when the designer or runtime loads the form. But what I did see implies there could be a lot of changes, or at least a lot of version mismatches.

    The majority of your form's UI is created at runtime, but I'm not 100% certain if you expect some of that to happen via the Load handler. It looked more like it came from button presses.

    But I also saw some code related to MDI parenting, which is odd because the screenshot didn't seem to imply an MDI application. And some code like ContainForm() isn't present, maybe it comes from a Module that wasn't included. And at least 10 controls I saw are probably some kind of custom UserControl that wasn't included, they'll have their own designer files!

    I think this form is too complicated to diagnose. Your best bet is to try and diff the files between a working version and a non-working one. The size of the file almost guarantees that will be too difficult.

    I strongly recommend the book The Art of Unit Testing by Roy Osherove. It's a small, approachable introduction to the idea of "testable coding", which is a fancy term for "try to write many small, single-purpose classes instead of few, many-purpose classes". Most developers agree that philosophy leads to code that's easier to understand, even though it has more classes.

    The analogy:

    Imagine you're looking at a well-organized garage, with a wall of many hammers, many screwdrivers, etc. You also have a Swiss Army Knife. If you need a No. 4 Philips head screwdriver, the processes usually work out as:

    Garage (many small classes):
    Walk to the screwdriver wall, look at the Philips head row, grab the No. 4.
    Multitool (one large class):
    Hey this looks like it might work, no, wait, it's too big, uh, let me flip it over and see if there's a smaller one... Ugh, well, here's the flathead blade? Ugh, too big... hey, look, if I use the nail clippers...
    The part people balk at is it takes time to learn how to organize the garage. The book I recommended is the first of about 4 I think teach the right principles. None of them focus on VB .NET, but the skills work in every programming language I've ever used.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  28. #28

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Thanks Sitten...appreciate the comments and advice. I've only got an A.S. in Computer Science and am pretty much self-taught when it comes to OOP. I'll take all the advice I can get.
    Blake

  29. #29
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    32,131

    Re: Using an old version of .Designer File?

    Quote Originally Posted by Sitten Spynne View Post
    You'd benefit greatly from learning how to use helper methods to implement the "don't repeat yourself" principle
    You've said that before
    Last edited by Shaggy Hiker; Jan 5th, 2018 at 10:23 AM.
    My usual boring signature: Nothing

  30. #30
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,580

    Re: Using an old version of .Designer File?

    There's going to be two parts to this post, because I do want to help with the problem at hand.

    The help:

    Let's say someone dumped this in my lap. I can't tell my boss, "Sorry, the form's too big." I have to do something.

    The first thing I'd do is try and get the project opening and building on another computer. For some reason, on large projects, that's always harder than the idealists make it seem. But the goal here is to answer the question, "Is the problem something unique to just my machine?" If that's the case, you can start the nasty process of rebuilding your machine. If not, then there's really something wrong with the project.

    You've got one leg up over most people: it's clear you're using TFS. So you can bend and break these files in any way you want, safe in the knowledge that you can at least go back to how broken it is right now. You can't make it worse, can you?

    The first thing I'd do is comment out or delete everything that is in the "main" file. Now run the form. Does it look like what you'd expect? If so, you've for sure got an event handler misbehaving. If not, you've just proved 14,000 lines of code aren't the problem, that's a big step.

    If commenting out everything solved the problem, your job is to one at a time start uncommenting things until the problem appears again. At first, "uncomment one thing" won't be doable, since your event handlers call otehr things and you'll have to uncomment those, too. So pick one event handler, uncomment it, then slowly uncomment other things until it builds and runs. If that fixed it, now you've narrowed down the problem to a few hundred lines of code. If not, keep uncommenting.

    Eventually you'll find the stuff that causes the problem. Now you can ask specific questions about that chain, or use breakpoints to debug and try to figure out what's going on.

    As an alternative, I might consider calling that file "cursed" and start over in a new form file. It's faster to reimplement something than it was to implement it, especially when you have all of the old code to look at. For a form this big it will still probably take several days. But how many days have we been sitting still?

    Try your best to implement ONE feature at a time. Then, when you're sure it works, commit that to TFS. At some point, the old problem may appear again. NOW you have a VERY SMALL diff to try and figure out what the heck is going on! Adopt this kind of "check-in very frequently" philosophy now and forever. A diff of 20 lines is stupid easy to read. A diff of 2,000 lines is impossible to interpret. Some people worry this "clutters" TFS. What good is a "tidy" TFS if it can't help you figure out what changes caused a bug?

    Reimplementation is also a very good chance to ask architectural questions. For example, while doing this you should ask things like, "How can I implement this method without GoTo?" or "Why do you hate whatever my EH module is so much, how would you do centralized error handling?" Those are good individual threads. Also while you're reimplementing: notice when you see things that look a lot a like. I saw at least a few instances of 20-30 line blocks of code that were identical in your file. Ask us how you can turn that repeated code into helper methods. It's easy to accidentally do 40 lines of code worth of work with 200 lines. It's generally harder to understand 200 lines than 40.

    I don't know how else to proceed. There's nothing glaringly obvious but, again, in 14,000 lines it's very hard to definitively say I've come to grasp everything in less than 3 or 4 days of analysis. Sometimes you have to tear it all down and start over. Even when that seems hard. Doing something is better than doing nothing.

    Longer-term advice:

    Do not let, "I don't have a piece of paper" stand in your way!

    Programming is a lot like mountain climbing. No one has a degree in mountain climbing, yet people still do it! The way you become a mountain climber is to climb a mountain. Preferably a safe one. When you want to climb a harder one, you find a guide. That person is an expert mountain climber, and has often climbed EXACTLY the mountain you are trying to climb. They can assess your skills and, sometimes, let you know it's likely you'll need more training and experience to tackle the mountain.

    Books can be guides, but you also have to participate in a community (like this one) and be unafraid to ask "stupid" questions. The harder thing to do is abandoning ego. People are going to tear your code apart. Developers are mean-hearted, cruel people for some reason. You also have to be completely willing to abandon your own practices when experts (rarely) agree they are terrible.

    Don't get stuck in the loop, "I've got more experience, I think I know more about this." It's not often true. Programming is a field with some general truths, but also lots of niches. When someone says "don't do this", look to see if they blessed you with a "because". If they didn't, challenge them to provide it. If they can't defend their opinion, feel free to ignore it. If they can, and you disagree, double-check to make sure you properly considered if they're right. There's a lot of stuff I say "don't do this" in VB .NET I'd be fine with agreeing "it's the best practice" in some other language.

    The books I'd recommend are The Art of Unit Testing, Head First Design Patterns, The Pragmatic Programmer, and as a shortcut to some others, Working Effectively with Legacy Code. As a side project, look on the internet for Bob Martin's SOLID principles, but don't listen to his political advice. If you can only read one of those, I struggle to pick one but Working Effectively with Legacy Code might be the most useful.

    It really cannot be overstressed that "more small classes" is dramatically easier to maintain than "few large classes".
    Last edited by Sitten Spynne; Jan 4th, 2018 at 02:04 PM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  31. #31

    Thread Starter
    PowerPoster
    Join Date
    Jan 2004
    Location
    Southern California
    Posts
    4,750

    Re: Using an old version of .Designer File?

    Thanks guys for your thoughts. I think this form is a "cursed" form and starting over with it may be the only answer.
    Blake

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width


×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.