I am doing reverse engineering of code that someone else wrote. When I search for all references of a variable or method and click on one of the results it beams my cursor right away on the line of code where it is used (which is a brilliant feature). Visual Studio shows me the class where this variable or method is used but not the method. The problem is that sometimes I end up in a huge method deep within, and the only thing I really need is the name of this cursed method.
Question: Is there a simple way to jump to the signature of the method in which the cursor is situated? Or any other way to find it out? (Besides scrolling dozens of pages of code upwards and likely missing it)
In Visual Studio 2015 on the top right of the code editing window there's a drop-down list that contains all the method in the current file:
When you move from one method to another inside a file, the selected item in this drop-down list is updated accordingly.
Therefore if you put the cursor in the middle of a method the drop-down list should automatically change the selected item matching the method you're in.
Now if you open the drop-down list and select the current method it should take you to the method's signature.
Following the advice by Andrea I did a little research. Combined with this answer the outcome is this shortcut series:
Press Cntrl + F2 this will shift the focus to the dropdown menues above the code.
press 2 times Tab which will navigate to the dropdown menue for class elements as #Andrea suggested,
and hit ENTER to confirm the selection, which will automatically jump with the cursor to the signature of the method!
Related
A while ago I was watching a video where the presenter cleaned up his code by highlighting already written code, and choosing some option that converted the code into a method. It also automatically recognized what parameters needed to be passed, and all he needed to do was name the method.
Does anyone know what this option is called? I have looked all over and cannot find it. I can't remember the video either.
It was probably refactoring. Highlight your code, right click and select "Quick Actions and Refactorings", then select "Extract Method". (Or choose Edit Menu > Refactor > Extract Method.)
You'll be able to change the name of the new method. Visual Studio does its best to figure out what types are needed as parameters, what should be returned, what visibility for the method is needed, etc. You'll still want to double check the result and make sure it does what you want.
Yes, it's called refactoring your code. You can extract a method by right clicking on the highlighted method and choosing Extract Method from context menu. VS will extract the method and set the parameters for you.
UPDATE3 - SOLVED with reservations, please see my solution below; leaving it open since the cause of the problem is unclear, and I don't know how robust the solution is.
UPDATE1: here's the short short version.
Currently, after .setEditText on a QComboBox, I get this:
so the next thing you type will overwrite 'Team '.
But the desired effect is this (unhighlighted / unselected), so that the next thing you type will be appended to 'Team ' instead of overwriting it:
Thanks for any help. The rambling details are below, which is the original post:
(this is all PyQt 5.4)
UPDATE2:
Apparently python doesn't think anything is actually selected:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:" and nothing else. To make sure that's working:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(0,4)
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:Team"
So that might be why many of the methods that affect selection are not working as expected (.deselect(), .setSelection(5,5), etc, and even some of the other methods give unexpected behavior, i.e. cursorForward(False,1) or cursorBackward(False,1) and such.
Original post:
This is for a radio log GUI, so keyboard interactions must be minimal and intuitive. openNewEntryForm (below) is called as a slot from a pushbutton on the main application GUI window:
self.ui.pushButton.clicked.connect(self.openNewEntryDialog)
It can also be called using a keyPressEvent in the same class:
def keyPressEvent(self,event):
if type(event)==QKeyEvent:
print("QKeyEvent:"+str(event.key()))
if event.key()==Qt.Key_T:
self.openNewEntryDialog('t')
event.accept()
else:
event.ignore()
Here's the method in question:
def openNewEntryDialog(self,key=None):
self.entryDialog=newEntryDialog()
if key=='t':
self.entryDialog.ui.to_fromField.setCurrentIndex(1)
self.entryDialog.ui.teamField.setFocus()
self.entryDialog.ui.teamField.setEditText("Team ")
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues()) # adds the log entry
so, the intended key press sequence is (from the main application GUI window):
a single keyboard press of 't' will open the entryForm, set the to_fromField to index 1 (which happens to be "TO"), give focus to teamField (also a QComboBox), set its text to "Team " and set itself up so that the very next keypress will appear as the text following "Team " in teamField.
So, starting from the main app GUI again, the plan is that typing 't3' should open the new entry window, set the to_fromField to "TO", and set the teamField to "Team 3", ready for a keypress of the tab key to move on to the next field in the entryForm.
The problem is that the teamField.setEditText("Team ") call leaves all of the text highlighted/selected, so that a subsequent key press of '3' would replace "Team " with "3"; I'm looking for a way to unhighlight/unselect "Team " but leave the cursor active at the right of that string, so that the subsequent key press of '3' would make the entire string "Team 3".
Ideas? Thanks in advance.
You can access the line-edit of the combo box, and then remove the selection:
self.entryDialog.ui.teamField.setEditText("Team ")
self.entryDialog.ui.teamField.lineEdit().deselect()
UPDATE:
The above code is correct, but it seems that the dialog will then clobber it when it initialises the focus handling for its child widgets after it is shown. If a dialog is opened with exec(), it will start its own event-loop, and some events (including focus events) will only be processed after it is fully shown. This is why it may appear that some changes made to child widgets before the dialog is shown are being ignored.
One way to work around this is to use a single-shot timer to ensure the changes are only attempted after the dialog is shown.
So add a method to the entry dialog class something like this:
def resetUI(self, key):
if key == 't':
self.ui.to_fromField.setCurrentIndex(1)
self.ui.teamField.setFocus()
self.ui.teamField.setEditText('Team ')
QtCore.QTimer.singleShot(0, self.ui.teamField.lineEdit().deselect)
and then use it like this:
def openNewEntryDialog(self, key=None):
self.entryDialog = newEntryDialog()
self.entryDialog.resetUI(key)
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues())
SOLVED with reservations, see UPDATE3 in the original post.
So, with the initial text all highlighted, tests show that it didn't actually think anything was selected. This solution was just stumbled upon by trial and error, fiddling with setting and clearing focus, selecting text and trying deselect:
def openNewEntryDialog(self,key=None):
self.entryForm=newEntryDialog()
if key=='t':
self.entryForm.ui.to_fromField.setCurrentIndex(1)
self.entryForm.ui.teamField.lineEdit().setFocus()
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(5,1)
Notice there are two spaces after 'Team' and the second one is intentionally selected. Then the very next keypress will overwrite that second space; that is basically the desired behavior.
Anyway it looks like something bizarro with the selection scheme; one way to look at this is that the highlight isn't really a selection, but, if you set a valid real selection then it will override the original highlighted 'pseudo-selection'. The original highlighting behaves like a selection in that a keypress will replace everything that's highlighted, but, not like a selection in that the selection methods reveal that there is no 'selection', see UPDATE2 in the original post.
Can anyone help explain this behavior? I'd like to build some more confidence in it before accepting this coincidental answer.
Thanks
I have need of using VBS in conjunction with the DAO.Field.Type methods and properties. Since I am using VBS I do not have access to the constants displayed on this page and I can't find a good resource that will tell me what they are.
Most specifically this MSDN article lists the constant names, but I don't know what their values are, and I would appreciate finding out what they are.
Field.Type Property (DAO)
Thanks,
Sean W.
Do you have Microsoft Office? Here's one way you can find them.
Open any Office product.
Hit ALT+F11 to open the VBA editor.
From the Tools menu, select References....
Find the reference entitled Microsoft DAO X.X Object Library, check it, and click OK.
Hit F2 to bring up Object Browser.
In the top drop-down, choose the DAO library.
In the 2nd drop-down, type your constant name (e.g., dbBigInt) and hit [Enter] to search.
Select the proper item from the search results.
Near the status bar is a pane that describes the selected item. It will show you the constant's value.
I am drawing the GUI using GTK+ with PyGTK.
I've created a ComboBox within a TreeView. But the problem is that when I first click an item, the dropdown arrow is insensitive (grayed-out). I had to click another item and then return to the item again to for the dropdown arrow to be sensitive again.
Is this standard for ComboBox in TreeView? If you have a fix in any other language, I can accept it as well.
An example can be found here.
He is facing some other issues but his code demonstrates the problem as well.
The problem with the code you are referring to above seems to be that the ComboBox actually only has 1 element when you start editing, which makes drop-down feature useless (and hence inactive). To make it behave as I suspect you wish, all you have to do is use another signal to execute self.populate_combo. I added two lines after the treeview was created to make it work:
treeview = gtk.TreeView(liststore_hardware)
sel = treeview.get_selection()
sel.connect("changed", self.populate_combo)
That is, I made the changed selection cause population of the Combos, which implied that they had more than one element in them when control was returned to the main-loop. And hence drop-down worked.
I also commented out the previous editing-started signal since it added nothing with the current structure of the program.
window.connect("destroy", lambda w: gtk.main_quit())
#self.cellrenderer_combo.connect("editing-started", self.populate_combo)
self.cellrenderer_combo.connect("edited", self.combo_changed, liststore_hardware)
Edit:
On second thought, the model is a None after __init__ has been run and not 1-length per row as I wrote above, which makes the lack of dropdown-features even more reasonable.
Comment:
The code you referred to and my change to it are both only rational if changing rows (or editing) causes a drastic need to rewrite the ListStore. I'm not really sure what type of scenario would demand that. If, on the other hand, the contents of the TreeView and the ComoBox' ListStore varies as a result of a search-action or filtering done else-where, then that search, rather than the change of rows should invoke populate_combo.
So an alternative solution in the scope of the code at hand, my suggested event above can also be commented out and a simple
self.populate_combo()
be added as the last line of the init function.
Further, should there be a need to re-populate the combos during the run of the app, I would suggest that the current ListStore is modified rather than creating a new one each time, if the changes are not expected to be major (in which case make a new is probably fastest and simplest).
Does Xcode have a way to show the caller function of a method? I want to know all of the calling functions of a method in a class. A solution would be to find the method in the project, but sometimes different classes have methods with the same name - That could find us a method we're not looking for..
Many other IDEs have this capability, such as Visual C++ 2003/2005/2008,Eclipse ...
Can you do this in XCode?
Xcode 4.4 intrudced this functionality:
New Features in Xcode 4.4 (Scroll down to 'Find and Search Additions')
Move your cursor on top of the function you are interested in
Open the Assistant editor(⌃ +⌘+Enter)
On the top of the assistant editor, Select 'Callers'
You will see a list of all the function that's calling your function
Not the as effective as other IDEs, but does the job.
Yes. Set a breakpoint inside your method, then when it breaks, there are two spots to see a stack. First is in Xcode's "console" area (usually the bottom middle), there is a top-bar which may not immediately appear to be navigable, but it is a select-style UI control which has the entire stack in it. Selecting a different level shows you that scope's variables, etc. and pops your editor to that exact file (where you can mouse-over variables to see their in-memory real-time values). Second is in the left-hand area (where you normally browse files). There is another tab there (besides the file browser) for exactly this purpose. There is a slider at the bottom which controls how many "steps" in the stack you see; clicking on one has a similar affect.
For simple refactoring such as method re-naming, you can use the contextual-menu when you right-click a selected method-name, and Xcode will replace all identical selectors in your project. However, this does not address what you mentioned about different classes having methods with the same signature. It does, however, give you a very nice interface for reviewing the changes in-context and easily accepting or rejecting them one at a time.
It might be noted, however, that changing method signatures often may be a sign of poor design, and particularly if you have to do it with methods which have the same signature on different classes (which are not "siblings" and therefore should both get the rename)