While using the amazing Python Jedi plugin from GVim, I have started noticing some odd behavior with function completion tips popup (not the autocomplete as far as I can tell).
Firstly, while the function argument helper popup is visible, GVim input becomes laggy, even for builtin functions and standard types. Once the popup is closed, lag disappears. Autocomplete seems to work just fine on all levels, this lag seems to only apply to the function helper.
Secondly, I recently had a case where a popup became frozen in the buffer, even after it should have closed, and actually replaced the contents of the buffer at that location in the file. I finished the function I was working on, and then used :/__init to jump cursor location. My window scrolled down, but apparently the original function popup didn't clear, and become a fixture in my text.
When I saved the file, that line was replaced with the popup contents (obviously threw an Exception when python tried to execute that line). Going back to that location in the file, reactivating that function help popup and then closing it again fixed the frozen popup text.
Are these problems related?
Is this an aggressive configuration setting that I should change. Honestly those popups are a bit too aggressive for my liking sometimes, so how do I disable/hotkey-bind them in the configuration?
I have only experienced this behavior in GVim. Maybe it happens in console vim, but I have not tried to reproduce the situation, so I don't know.
GVim circumstances:
7 tabs open
each tab usually has two vertical windows
each window is usually a separate python module
There's a multitude of issues about this on jedi-vim's issue tracker: https://github.com/davidhalter/jedi-vim/issues/217. The whole lag situation is slowly getting better.
One of the easiest solutions is to just disable call signatures:
g:jedi#show_call_signatures = "0"
As of now (I just merged that), there's another way of displaying call signatures:
The call signatures can be displayed as a pop-up in the buffer (set to
1, the default), which has the advantage of being easier to refer to,
or in Vim's command line aligned with the function call (set to 2),
which can improve the integrity of Vim's undo history.
You could try if you like this better (but you have to update jedi-vim):
g:jedi#show_call_signatures = "2"
Related
I created a main window win:
win = Curses::Window.new(Curses.lines / 2, Curses.cols, 0, 0)
Then I sometimes need to create a message window, that covers the main one. After I close the message window, I refreshed win:
win.refresh
But unless I change anything in the main window using something like:
win.addstr("asd")
refresh doesn't redraw the window.
Is there a way to force redrawing the window?
It depends.
That's done using touchwin (or whatever name a Ruby binding may happen to use for the C function).
In ruby 2.0.0, the standard curses binding for Ruby lacked touchwin and touchline. Oddly enough, it included bindings for several of the ncurses extensions (resizeterm, the mouse interface, default-colors), but lacks many of the standard features (see X/Open Curses for reference).
In 2.4.1, curses is not a standard Ruby module, but the site for the module does have touchwin.
There is a method Curses::Window#touch which marks window as changed and to be redrawn by next refresh. There is also method Curses::Window#redraw which simply redraw the window.
Additional problem is getch method, which in my program is little bit unpredictable if I use Curses.getch - sometimes it causes that the window wont refresh, sometimes it causes whole screen to disappear... Using getch on window object solves the problem e.g. win.getch
In child window of my application, I have placed one single line edit control named as sle_name. Its tab order is 1.
Below that control I have placed DataWindow having formatted as free form style.
When I run the app, if my focus is in sle_name, and I click on sle_name then rbuttondown event is triggered. Then I move my focus to DataWindow(dw_account). Once I got focus on dw_account and then if I try to click on sle_name, my focus is not moving on sle_name and neither I can run rbuttondown event on sle_name.
What is the reason for this problem?
One more thing: when I start this window my focus in set in sle_name, from that control if I press tab key then my focuse moves to dw_account and if I press again shift+tab then my focus is moved back to sle_account.
But if I try to set focus from dw_account to sle_account using mouse pointer it is not moving focus.
What is the reason behind this behaviour?
I had the same behavior in a child window.
It was fixed when disabled the 'ControlMenu' and 'TitleBar' properties in the window. (It's so strange).
Hope it helps
Juanma
This isn't natural behaviour, so the cause is likely something you've scripted. Depending on your architecture, the culprit code could be a number of places (e.g. framework objects). If this were my problem, I'd run with the PBDEBUG trace turned on (a System Option in the IDE, or /PBDEBUG on the command line after the deployed EXE name), and see what is firing when you try to move back to the SLE.
I'd also be using PBL Peeper to see the trace and the code side-by-side, so it's easier to see what code is being executed (the trace only shows you script name and line number).
Good luck,
Terry.
you must have to create the event ID pbm_lbuttonup, with the same parameter as rbuttondown event. Then in the code you write this.setfocus()
Babylon dictionary and a couple of other dictionaries allow to click on any word in any windows program
and automatically recognize the word under the cursor, and at once open the dictionary window while searching for that word in installed dictionaries.
You can on the other hand open your dictionary, type in your word and press Enter, the result will be the same.
There's a Delphi form, containing a text label, for example with the word "Automaton".
My question is:
How to send a word from my Delphi application right into the dictionary window, as if you typed it manually and pressed Enter?
The best solution is to send some message through the Windows mechanism, but if it is too complicated, there's another solution, and so the second answer: as I described, we need to model a [Ctrl+left mouse] click on a form where this word is displayed on a form [ a visual label on the screen of my Delphi application], to be exact, on some central pixel of this label.
Could you kindly give an advice how to do one thing or another in Delphi ?
** edit:
The problem with AppActivate is this: Babylon dict has a daemon part that seats in the tray.
In the task manager a real window where the text should be input also is named 'Babylon'.
So AppActivate('Babylon') tries to bring to front the non-visual part of the application.
Do you have any suggestion how to determine the windows handle or something of a real visual part of the application? In the task manager, I repeat both visual and non-visual parts are named 'Babylon'.
I cannot offer an answer so much as some insight and advice...
There are certain applications which "intercept" keyboard and mouse instructions, and essentially "nullify" them if they are being immitated by software. Generally-speaking, you'd only see this in proper AntiVirus software such as Kaspersky by design... however:
The way some (not many, but some) programs hook keyboard and mouse inputs, as a side-effect, behave the same way. If you have attempted all of the advice given as comments above, and cannot get Babylon to trigger an action as a result, it is likely Babylon behaves as I have described.
If what I suspect is true, then the method you are attempting is simply not possible (at least, not using any simple Pascal code on its own... ASM might be able to do it but that's beyond my knowledge).
A better solution may be to do a little research to see if any of the following options are available to you:
1) Does Babylon have a Pipeline or API you can use to interface your application(s) with it?
2) Is the particular functionality you require of Babylon accessible through one (or more) DLL files distributed as part of Babylon?
3) Is there an alternative to using Babylon for your needs?
I know it's not an answer as such (certainly not one you'd want to hear), but it may point you in a better direction.
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!)
I'm creating a ToolTip window and adding tools to it using the flags
TTF_IDISHWND | TTF_SUBCLASS. (c++, win32)
I have a manifest file such that my program uses the new WindowsXP themes
(comctrl32 version 6).
When I hover over a registered tool, the tip appears.
Good.
When I click the mouse, the tip disappears.
Ok.
However, moving away from the tool and back
again does not make the tip re-appear. I need to hover over a different tool
and then come back to my tool to get the tip to come back.
When I remove my manifest file (to use the older non-XP comctrl32), the
problem goes away.
After doing some experimentation, I discovered the following differences
between ToolTips in Comctl32 version 5 (old) and Comctl32 version 6 (new):
New TTF_TRANSPARENT ToolTips (when used In-Place) actually return
HTCLIENT from WM_NCITTEST if a mouse button is down, thus getting
WM_LBUTTONDOWN and stealing focus for a moment before vanishing. This causes
the application's border to flash.
Old TTF_TRANSPARENT ToolTips always return HTTRANSPARENT from WM_NCHITTEST,
and thus never get WM_LBUTTONDOWN themselves and never steal focus. (This seems to be just aesthetic, but may impact the next point...)
New ToolTips seem not to get WM_TIMER events after a mouse-click, and
only resume getting (a bunch of) timer events after being de-activated and
re-activated. Thus, they do not re-display their tip window after a mouse
click and release.
Old ToolTips get a WM_TIMER message as soon as the mouse is moved again
after click/release, so they are ready to re-display their tip.
Thus, as a comctl32 workaround, I had to:
subclass the TOOLTIPS_CLASS window and always return HTTRANSPARENT from
WM_NCHITTEST if the tool asked for transparency.
avoid using TTF_SUBCLASS and rather process the mouse messages myself so
I could de-activate/re-activate upon receiving WM_xBUTTONUP.
I assume that the change in internal behavior was to accommodate the new "clickable" features in ToolTips like hyperlinks, but the hover behavior appears to be thus broken.
Does anyone know of a better solution than my subclass workaround? Am I missing some other point?
You're not the only one who has hit compatablity issues with tooltips between these DLLS.
I too have had nothing but trouble with the new tooltips in the themable common controls. We have already been monkeying with mouse messages and active/deactivating the tips before adding the manifest and theming our application - so it sounds like what your doing isn't too crazy.
We're still living with problems with TTN_NEEDTEXT messages being send constantly as the mouse moves (not just when hovering), positioning problems with large tips (maybe not something new), and odd unicode messages being sent instead of the ANSI versions (which I plan to post as a question at some point).
I don't know, but this sounds like a really "hard" problem (in the sense that all real-world) problems are really hard. I bet the underlying problem is something to do with the setting of the focus. Windows that manually do that are evil and generally suffer from all manner of bugs.