We have a VS solution containing multiple VB projects. From time to time, some of the Handles clauses from procedure declarations get lost (which, for example, seems to happen when moving a control from one container to another one), causing non functioning buttons etc. in our software.
We're in the process to add an AddHandlers() sub to every class, in which we add the handlers manually, so Handles clauses will no be longer necessary. Until then, we have to keep an eye on those disappearing clauses.
Though we use Subversion, we don't always notice that a clause got lost.
Is there a we can have Visual Studio automatically check for missing Handles clauses? Maybe we could use some mighty black magic regex stuff for this task? Anybody have an idea?
Related
I'm refactoring an existing VB.net application that is ~6,000 lines in one file, and I've encountered a dilemma.
On the one hand, I can use visual studio's Data Sources and drag-and-drop functionality to get rid of all the hand-written code that sets up the DataAdapters, DataSets, DataTables, CurrencyManagers and the manually linking between them all.
On the other hand, I can separate the logical pieces of my UI into User Controls.
Now, if I only do the first one, I end up with tons of controls all in the same form, which causes me to have tons of controls in the same 'namespace' that I have to manage, and forces me to write all custom UI logic and event handling in the code behind for the single main form.
If I only do the second one, I get the distinct visual pieces of my UI in separate files, which gives me an appropriate place to write specific event handling and formatting code; but it doesn't let me use the visual studio designer to hook my dynamic components (e.g. DataGridViews) up to the BindingSources in the parent form. The nice thing about this is that I get to set the myriad properties (column width, read-only etc.) in the GUI, which seems like it would make the project much more maintainable.
What's the sensible course of action here? Or is there some possible way to employ both tactics (which is what I would ideally like to do)? I'm definitely looking for some guidance here - I'm a complete vb.net newbie.
Thanks!
First, thank you for taking pity on me and reading this issue. I CANNOT for the life of me figure out what extension I might have installed that is causing this issue, but it is EXTREMELY cumbersome.
Whenever I begin to type code (VB I think it also occurs in C#), for example "For Each" once I hit the F it forces a set of parentheses. Which would look like F(), but because I keep typing it looks like F(or). This only occurs when coding inside code blocks like a function or a sub, but when I'm creating the function it does not occur. I've disabled any and all power tools and the like, or at least I'm 90% sure I've done this for all of them, and yet it still occurs.
I'm usually pretty proficient at digging about the net and finding the answer, but for this one I'm at a loss. There is just too many keywords involved, so all I see is non-related topics, or how to make the parentheses occur, not get rid of them.
If anyone can provide some steps to resolve this, I'm happy and eager to try them. It's just such a hassle to live with for right now.
If you think it is a Visual Studio extension, then start by disabling all of them and adding them back one at a time.
You can also run VS with the command line switched to disable features.
Devenv switches
The simple answer to the cause is the Codealike VS Extension. I logged a bug with them and hopefully they'll fix it soon
I maintain an old vb.net project that I didn't make and I was wondering if there's an easy way to determine which parts of the software is still used today by the staff where I work.
I would like to log all function calls without having to edit each one of them if possible.
The project has 27 forms and 6 modules.
Any ideas?
Thanks!
There is no way to 100% determine everything that is used by the system. Vb.Net supports dynamic invocation of methods / properties. Hence you can't even do tricks like delete some code and see if it recompiles. Even if it compiles it could be invoked dynamically.
One way to get a sense of what code is used is to profile the application. Start up the profiler, run the app and go through all of the ways in which the app is used. The resulting profile should give you a good sense of what parts are used. It's very possible though this approach will miss code though
I'm currently trying to write a program in VB.NET which fluidly changes the DWM window colorization colors in Windows 7.
I first tried to edit Registry values directly, but I had to restart the UXSMS service. This solution was unsatisfying, because of the toggle of the taskbar.
I'm now searching for a function in a DLL such as user32.dll or themecpl.dll which can reproduce the behaviour of control panel when setting the window color.
I'm now on IDA, searching for the adquate function (CColorCplPage::SetDwmColorizationColor seems good!). If anyone has one, please share it!
(If anyone need screens or code, please ask. Sorry for my poor English.)
Your first attempt failed because manually editing the Registry is never the correct way to change system settings. As you found out, lots of Windows components (and other applications!) read those configuration values once and cache them, preventing your changes from being propagated. Another problem (and you'd be surprised how often I see this) is applications that attempt to muck around in the Registry generally end up corrupting things.
Instead, you should call the documented API to change the settings. There's almost always a documented way of doing this, and if there isn't, well then you shouldn't be doing it.
This appears to be one of those cases. There's a documented DwmGetColorizationColor function, but there's no corresponding DwmSetColorizationColor function, as one might expect.
The reason is that the user is supposed to be the only one who can change their colorization settings, not other applications. You might promise not to abuse this, and to only make such changes at the user's explicit request, but not all applications can be trusted to do this. Lots of people would use it maliciously, so these functions have not been documented and exposed.
But as usual, if you press on, you can usually find an undocumented way of doing things. The problem with using undocumented functions is that there's no guarantee they'll work or continue to work. They've been intentionally left undocumented because they're liable to change on new versions of Windows. You should only use them at your own risk.
In this case, if you use a program like DumpBin to obtain a list of all the exported functions from the DWM DLL (dwmapi.dll), you'll see a number of undocumented exported functions.
The ones you're interested in are DwmGetColorizationParameters and DwmSetColorizationParameters. Both of these functions take a COLORIZATIONPARAMS structure as an argument that contains the values they need.
So, you need to reverse engineer these functions and obtain the appropriate definitions. Then, you can call the DwmGetColorizationParameters function, passing in a COLORIZATIONPARAMS structure to obtain the current configuration settings; modify the member of the structure that contains the current colorization color; and then pass that modified version of the structure to the DwmSetColorizationParameters function.
Did I mention that I don't recommend doing this?
This should be a community wiki question.
I've had to work with a lot of vb.net lately, and recently created the following expression.
If If(report.IsPublicReport, False) Then Return True
Now, this is a simple coalesce inside of an if statement, nothing to be scared of. However, when I was scanning the method looking for an error I had made, this line would constantly stop me dead in my tracks. I just couldn't scan it. Every time I had to stop and break it down manually in my head. Largely because I had to stop and figure out what each If was actually doing in the expression.
I have since rewritten the line as
If report.IsPublicReport.GetValueOrDefault() Then Return True
While more verbose, I am finding that this disrupts my train of thought less as I am scanning the code.
This got me thinking,
Is this something other more experienced
VB.net developers are running into?
Are there any other types of
expressions that are largely
avoided, or at least not favored?
Am I just whining about nothing?
As long as you are uncomfortable with VB.NET syntax, I would strongly recommend you use Option Strict On so you catch mistakes like these quicker. The best way is by changing it globally so it is always on by default. Tools + Options, Projects and Solutions, VB Defaults, change Option Strict to "On".
What you're describing is something Scott Hanselman (and probably others) call "Code smell".
It's basically the idea that when you look at a piece of code and something doesn't seem "right" about it. This is not a capability that developers just "have". It's something you develop over time as you read and write more and more code.
It's not just VB either, you'll see plenty of idiomatic constructs in every language that will (or should) make you pause and question what you're looking at.
That Double IF would definitely do it for me
In Vb.NET you can write:
row!FirstName = "Test"
instead of
row("FirstName") = "Test"
A while ago I used to write row!FirstName (you can do that with every item in a collection that can be accessed by a string parameter) because I thought that was a good idea because it looks more statically typed (like person.FirstName as a property) and is shorter.
However I realized that this is not a good idea because after changing "FirstName" to "Name" i often looked for String in the current file which are highlited in Visual Studio (the object!param syntax is not).
Which makes finding them harder.
You can write
Private Sub Form1_Load() Handles MyBase.Load
End Sub
instead of
Private Sub Form1_Load(ByVal sender As System.Object, _
ByVal e As System.EventArgs) Handles MyBase.Load
End Sub
which is fine if you don't need sender or e (I suppose it is just some compiler magic that adds the signature itself) but I refuse to use the shorter way, cause you don't recognize it as an eventhandler at first sight.