What does VS Code editor.overviewRulerLanes setting does? - settings

I can't figure out what the "editor.overviewRulerLanes": 3 setting does, as it does not change the number of lanes in the overview ruler and I can't find an answer anywhere, including VS Code's documentation.
"editor.overviewRulerLanes": 0 shows this:
What is "editor.overviewRulerLanes" supposed to do?

The setting doesn't do anything in VS Code. There must be some piece of code somewhere that always sets that value to 3. I think the setting should be removed from the JSON schema.
In the editor powering VS Code (which ships as the Monaco Editor) and can be executed at https://microsoft.github.io/monaco-editor/playground.html , the setting overviewRulerLanes does have effect. For example overviewRulerLanes: 1 reduces the "vertical lanes" from 3 to 1 and makes all the rendered decorations look wider:

Related

IntelliSense, Go to Definition, Docstring display only works for subset of opened documents

Expected behaviour:
Ability to use IntelliSense autocomplete, Go to Definition feature, Docstring display on hover, etc.
Actual behaviour:
The features mentioned above only works on a subset of open documents (usually only one)
Example repro:
I opened two golang files in the same session. In the example below I get expected behavior for server3/main.go but do not get expected behavior for server2/main.go. The behavior is not deterministic in the sense that sometimes the behavior can be flipped between between two files.
Image 1
Image 2
EDIT: I found that the features only work on a single bottom level folder. Does anyone know how to make the features works across all sub-folders in my open session?
Have you tried https://github.com/golang/vscode-go/blob/master/docs/settings.md#buildexperimentalworkspacemodule ?
"gopls": {
"build.experimentalWorkspaceModule": true
}
For backgrounds: https://github.com/golang/tools/blob/master/gopls/doc/workspace.md#multiple-modules

In Visual Studio Code, is it possible to Edit the MiniMap View with settings

I'm updating some legacy code, because of my unfamiliarity to it, Its very difficult to find structures, especially if I step away for a week for other projects.
To alleviate this problem I've gone back to my old-school roots and started adding ascii text-art as comments above sections of code, using this tool:
http://patorjk.com/software/taag/#p=display&h=3&v=1&f=Big%20Money-ne&t=Reveal%0ACheck
This allows me to see via my MiniMap the titles of functions or sections of code I might need to come back to
The Thought then occured.. well surely someone else has this problem, and since VSCode seems to be written by the community, maybe someone has already written a plugin that would search the code for function titles (like Javadocs?) and display the title in a readable size?
If not, would it be easily coded? i.e. is the minimap just a very shrunk down copy(not easy) or is it structured and can be parsed and tweaked?
As long as your language plugin supports it, you can use cmd + shift + o to go to function definition.
All functions should also be listed in the Side Bar under "Outline"

VB6 Form will not resize when I run

I have to make some modifications to a VB6.0 project that I haven't touched in years so my memory is getting a little old.
I have a form and then I make the form bigger in the IDE. When I run the program, the size increase does not show up although it looks perfectly fine in the IDE.
What could be causing this?
If I change other stuff on the same form, the changes show up when I run. The only thing this is happening with is the size.
This form is a lot smaller that the main window so there is space to expand into.
Other forms in my project do not have this same behavior.
What else could I check for?
Look for something that sets the height and width in code at runtime. Use the IDE's search specifically to look for ".Height" and ".Width" and ".Move".
I think that an easier solution might be to set the form's height and width in the form_load event, so it initially becomes as big as desired.

Change the size of a control in lightswitch beta

I'm playing around with my first lightswitch application and am trying to change the size of a list control. Does anyone know how to do that? I've tried:
this.FindControl("PersonList").SetProperty("Height", 200);
but get told the height property doesn't exist. I've had a quick look thorugh the lightswitch namespaces in the object browser but so far haven't found anything useful.
That code looks like it should work (just change 200 to 200.0 - Height is a double). I've just verified almost identical code on my machine.
Here's a few things you can try:
Ensure you're using the right name for the control - Select the control in Visual studio and check the name in the properties window. Lightswitch creates lots of name variations, and it's easy to miss that the actual name is "PersonList2" for example.
Ensure that you've selected "Pixels" for height control in the properties window for the control
Once you can access the Height property it won't actually do anything until you set the control alignment to "Top". If it remains on "Stretch" it will ignore anything written to the Height property.
Let me know if you still have trouble getting this to work.

VB6 silently deleting huge chunks of control data from forms

My project has maybe 130 controls (total of all labels, textboxes, etc.) in an SSTab (4 tabs). The project loads fine, it runs fine, I don't see a single error or warning at any point, but when I save the form with the SStab on it, the SStab data isn't saved (it is completely gone). Normally the relevant portion of the .frm file looks like this:
Begin TabDlg.SSTab SSTab1
Height = 8895
[1550 more lines of code for all the controls]
Width = 540
End
Begin VB.Menu FileMenu
But lately it's getting cropped to:
Begin TabDlg.SSTab SSTab1
Begin VB.Menu FileMenu
This is very frustrating! In my VB IDE, the frame, sstab, and all the controls are there, editable, running/compiling fine, no error messages at any point, but when you save the file, 1550 lines of precious sstab data just disappears - again, with no warning or error messages. So if you exit and restart the IDE, you get a form load error because 60% of the code is now missing. The log file points to the first error it finds (in this case a Begin TabDlg with no End) - there's no other info in it. (The log file was generated after the code was deleted and saved, so it makes sense that it wouldn't be helpful.)
When I first posted this question, I thought it had to do with the number of controls, because it appeared after I added a control, and in my first few tests, seemed to disappear when that control (or other controls) was deleted. Now I can't seem to get that form to save under any circumstances, even when I delete many controls (bringing the number of controls far below where it was when it was last stable).
I also tried deleting the SStab and moving all the controls to 4 different frames. I successfully did that in the IDE, but when I saved, a huge chunk of the data (starting with a slider control) was missing. So I have no fraking idea what is going on.
The problem is reproducible on two different PCs, so it doesn't appear to be a hardware/corrupt software VB install issue.
Has anyone else run into something like this?
Create a UserControl for each tab. That makes editing MUCH easier. It also allows you to nicely modularize the code, so each tab lives in its own file, and it'll allow you to reuse tabs elsewhere if you want.
Sounds horrible, never heard of anything like that.
Presumably you aren't getting an error log file from VB6 when you load the form into the IDE before it gets corrupted? The log file has the same filename as the form file but with a .log filename extension. For example, if errors occurred when loading Myform.frm, Visual Basic would create a log file named Myform.log. The error messages you might see there are documented in the manual.
Have a look in the Windows Event Log, see whether it records any interesting problems against the VB6 IDE?
Are you using any weird controls? Maybe one of them is somehow corrupting the FRM or FRX. FRM files are just text as you obviously know & the format is documented in the VB6 manual. Can you see any corruption in the FRM in a text editor? If you remove any properties defined in the FRX, does it still fail.
I think I would try creating a new project and a new form, and then use the IDE to copy and paste all the control definitions into it - no code. Play with the new form, see whether it has the same problem. Maybe you can recreate the form this way without the problem. If the new form does have the problem, do the same thing but only take half the controls. Maybe you can find a problem control by "binary search".
I get the same problem when attempting to save a form when the .FRM is writable but the .FRX is read-only
Not sure if this is the issue, but on a VB6 form, there is a limit to 255 (or is it 256) named controls. Perhaps you are running into that?
One way around that limitation is to use control arrays. For example, if you had 10 labels, instead of label1, label2, label3, etc, you could do label(0) through label(9), and use up only one named control.
The other thing worth mentioning about the SSTAB is the way it shows/hides controls. While it may appear that the controls are on separate tabs, what is really happening is that the controls are getting moved waaaayyyyy to the left (and consequently out of view). Perhaps with so many components, the SSTAB is choking on this in the IDE as it tries to render the controls in design view?
Again, not sure if this is the issue, but I know these two tidbits are relatively unknown.
So the SAVE function is not working.
I suspect one of the components you are placing on the tab strip is the culprit.
So ..
1) Take an inventory of each and every kind of component you are placing on the form
2) eliminate one (kind), SAVE
3) Did it SAVE?
-> Yes = that was the problematic control
-> No = return to step 2, but pick another kind
Of course, its important to remove all controls of a certain kind in step #2 (for example, ALL labels, or ALL textboxes, etc).
I have never heard of this happening however.
You are not alone! I've seen this problem. . .in fact I'm dealing it right now, which is what brought me to this site.
I've been working with VB since '94 (VB3) and I first saw this problem about 5 or 6 years ago, while using VB6. My solution then, was not unlike some of the suggestions that you have recieved from the good folks who've responded above: throw out the existing file and rebuild the form in a new file. I did that back and the affected form has worked ever since.
My current problem is appearing in another, much newer form, and the replace/rebuild option (performed about a month ago) only worked for about three weeks. Now the problem is back and each new iteration of the file gets corrupted very quickly. Following the reply above regarding the total number of allowable controls, I'm looking into just how many controls I have. . .and, as it happens, I was in the process of consolidating the primary the buttons and menus into control arrays, simply because it was going to streamline their management.
I can also confirm your observations about moving the project to a second PC. . . I've done that too, and problem persists. Moreover, I can add that I have moved the project from one shared storage system to another to no avail. (The original storage location was on a drive mounted to a Win-tel system and the new location is on a UNIX-based NAS!)
Just rebuilt the file again and checked: Controls.Count = 62, so I am no where near the 255 control limit mentioned previously. This is indeed strange! (Not to mention furstrating!)

Resources