We are using the TaskDialogIndirect function to report all type of messages in our application. The problem I see with TaskDialog is that it automatically truncates unbreakable text with ellipsis on both sides and there seems to be no way to avoid this behavior. So for example I am unable to display a file error with the full path of the file because the path gets truncated. I even tried the TDF_SIZE_TO_CONTENT flag which should auto resize the dialog based on the content but it only works for slightly longer paths and truncates again.
Anyone got any ideas on this? Any workarounds?
Related
I have a form onto which I have placed an unbound text box. This box is designed to calculate the total of 4 other bound text boxes which have simple numerical values in. I have used the expression builder in the unbound text box to set its control source property i.e. =([box1]+[box2]+[box3]+[box4])
When I first put this in it works fine. However after I close and then reopen the data base the box sits on the form saying #NAME? as if it has lost its control source. I have checked the data source after and nothing seems to be wrong. Any ideas why its happening. Its a pain as I have a button which when pressed opens a report based on the value in the unbound text box.
Try using Nz:
=Nz([box1],0)+Nz([box2],0)+Nz([box3],0)+Nz([box4],0)
Not entirely sure why it now works but I have re added the text box and the calculations into the source code and it seems to be fine. Perhaps just a glitch in my previous attempt... I used the =sum solution rather than the =Nz solution. Maybe my version of access or my data base is just fickle... thanks anyway
All:
I wonder if anyone could give me some clue that how to track the bug in D3.
For example, I draw a linechart, and I got some error from D3:
Error: Invalid value for <line> attribute y2="NaN" d3.js:7571
And this error is most possibly caused by some illegal(no value or NaN or etc) data binding in my code, but how can I trace back to locate where this error happen in my code rather in D3?
Thanks
I find that using the console in the Google Chrome browser is useful.
This can be enabled by pressing F12 when on the offending page and a separate window will open at the bottom.
The console tab on this window will present with information on errors found in the page.
As an example I inserted a 'random' semicolon in my d3.js code here;
(this is in the 'Geany' editor)
And in the console tab the error is identified as follows;
This shows you a description of the error and an indication of the area. In this case the console errored on the following line because it regards the semi-colon as valid, but that makes the following code invalid, but you get the idea.
In Firefox there is a plug-in called firebug I believe that will allow the same thing.
From my experience, there's isn't a really good way to debug this kind of error, but there's a workaround.
The error is thrown when an attribute value is set to NaN. Actually, that by itself would be easy to debug, because you could expand the error in the console and look through the stack trace to find in which file and on which line within call the stack the NaN value is set.
But that becomes impossible when you also have a transition. That's because the attr() call that's ultimately responsible for setting a NaN value runs asynchronously (i.e. via setTimeout at a later time). So you no longer get a stack trace that lets you see where in your code the NaN came from.
So, as a workaround, you can temporarily comment out all the transitions in your code, reload the page and you'll get an error that'll point you towards the line with the bug.
If you don't want to do that, then the only other option you have is to look at your code. You can narrow things down to the places in the code where you set attributes on a <line> node (since the error is about a <line>). Then you can insert a debugger statement in that general area and step through your code to find what causes your it to output NaN.
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"
I am working with an edit control in a dialog--all MFC. The only style specified in the resource is ES_AUTOHSCROLL. The dialog comes up and displays correctly. The edit control also works and edits text correctly--up until a point. At that point, it stops displaying text completely. The edit control is just blank.
My first thought was to try and adjust the limits of the edit control by sending calling SetLimitText() on the edit control which just sends EM_SETLIMITTEXT. I set a big number which was 10x the previous limit, and verified by EM_GETLIMITTEXT that the number retrieved is equal to the number set. After that, I still have the problem and nothing is changed.
Next I tried trapping EN_MAXTEXT and EN_ERRSPACE. Neither one of those notifications was sent.
Lastly, I started trying a little different input, and if I entered a space or a period then I could get a few more characters displayed than if I entered a W. The font in the dialog is MS Shell Dlg which on my system maps to Microsoft Sans Serif. It's a proportional font, do different characters have different widths, so I was beginning to thing that maybe it was GDI related.
Next, I trapped EN_CHANGE, and when it is fired off, I went and created an IC for the display, selected the font into the IC from the edit control, and then called GetTextExtent() on the text in the edit control. The problems occur in display right around 32760 which is darn near the 16-bit signed integer limit.
So, I am thinking that my problem is GDI related in that the EDIT control cannot draw past that limit. I tried substituting a RICHEDIT2 control, but it displayed fewer characters before going blank.
The other weird thing is that if I keep on entering characters and call GetWindowText() on the edit control, all the characters will be returned. It is just that the edit control is blank.
Yeah, maybe I shouldn't be displaying that many characters, but it is what it is.
Does anybody have a better explanation, solution, or workaround?
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!)