I'm working on some legacy code. I have a user control with a VtChart (VCI First Impression Library) in it and I'm trying to make changes to it, namely, adding another series to the control. However, every time I make changes to the control, close the form editor, then reopen it, the changes are gone.
I can't find any documentation on this control, so thought I'd ask the community, any ideas?
Ah! Found my answer. Since VtChart is connected to a grid (F1Book), the SsLinkRange needs to correspond to the number of columns needed in the chart. For example, if you want 3 columns, SsLinkRange should be A1:C10, where A and C is the column range. If the SsLink properties don't match it won't save the settings.
This is an very obscure problem, but I'll post this answer anyways for archiving.
Related
first post to StackOverflow, though I've been finding great tips for a few years here. Hope to resolve a vexing problem with handsontable.
I have an application that presents a handsontable instance with several columns whose content/format is dependent upon the value in a cell in another column. I determine the content and format of the dependent cells by way of a database query and server-side processing, the results of which are sent back to handsontable for processing in the afterChange function.
My problem is that whenever the user updates one cell in the table, ALL cells blink while the code laboriously reconsiders the formatting for ALL cells in the table. The preferred behavior would be to ONLY update the cells for which the formatting has changed, i.e., that small set which is dependent on the value that changed in the first cell. It's only these dependent cells whose contents are being changed anyway. Why redraw the WHOLE table??
I have searched and search here and elsewhere, and the closest to an answer I could find is that this is the intended behavior for the table. I don't agree...when the table is anything larger than 10 rows, the updating process is painfully slow and distracting to the user.
Any suggestions? I'm open to directly editing the handsontable js code, but would prefer to flip some flag I'm unaware of if possible.
Thanks all!
afterChange fire only one time for the cell you just updated (documentation example).
Your problem might come from an afterChange "chain reaction". The first afterChange modifies one or more related cells, triggering others afterChange and so on. If that's the problem, you can put a filter on the source parameter.
Another solution could be to work on a copy of the data to do your updates (see data binding), and once everything is fine, inject it back on the table with loadData, and ignore the loadData source in the afterChange callback.
Finally, if you still have some performance issues, you can check the performance tips, and remove any option that might slow your table (example with columnSorting)
(sorry I can't use comments to identify precisely from where your issue come...)
I'm working on a document-editing application using CKEditor, where the user can open multiple documents side-by-side in a pair of editor instances.
Most of the time, the user will be editing two different documents, but it's also possible that the two editor instances might contain different views of the same document. That makes things tricky, since I'd like to changes in one editor instance to be immediately reflected in the other instance.
Without hacking the CKEditor core, is something like that possible?
If not, would it be possible to write a plugin that would provide that kind of functionality?
What about if I was willing to get into the core code and hack around a bit? How difficult would it be?
This is a very similar case to a collaborative editing like Google Docs allows. The only differences are that you won't need to synchronize this via network and that it's very unlikely (if not impossible) that the same documents will be modified by two users at the same time. This makes things simpler... a little bit.
A year ago me and my colleague (we are both CKEditor core devs) took part in Node.JS Knockout and our plan was to create a collaborative editor based on CKEditor. It was only 48h, so the result is not impressive, but it worked. The source code is here.
The main problem you'll have is applying changes from editor A to editor B without breaking a caret position in editor B. Basically, you cannot just take data from editor A and set them in editor B, because everything in editor B will be reset including scroll position and caret. Unless this is not a problem, but I assume it is.
So you would need to:
either find a nice algorithm for extracting changes (like diff, but working on a DOM tree, not an HTML string) made in editor A and an algorithm to apply them to editor B (and this is what we implemented on Node.JS Knockout),
or find a way to guess caret position after resetting data in editor B; for example you can remember the caret context in editor B before setting data and try to find it in data that will be loaded.
Both ways are doable, but the first way will give better results if you'll implement it well. However, if your you don't know enough about DOM and contenteditable, then this task may overwhelm you. In this case I would advise to block possibility of opening one document twice.
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.
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!)
For reasons unknown, the VB6 compiler often likes to reorder the contents of .vbp files and the control descriptor block at the top of .frm files (The code that describes the properties of controls on the form. Code that you don't see in the IDE but you do see in a text editor and when doing diffs against the previous revision in version control.). This is monumentally annoying and very distracting when comparing revisions of a file.
Is there a way to prevent this?
I don't think there's much you can do about this. I've noticed the same problem: the IDE likes to rearrange things for seemingly no apparent reason. Some things I've noticed:
When you use the SSTab control, VB
likes to rearrange properties for
tabs, especially the TabEnabled
property.
For project files, it randomly
rearranges the order in which files
appear and I think I remember seeing
cases where similar file types are
not always grouped together and end
up mixed in with the project
properties. You don't have
much control over this, unless you run all your VBP's through some type of sanitizer that groups like files together (forms in one group, modules in another group, etc.) and sorts them alphabetically or something, so that they remain consistent. One possible way to handle this could be to write an IDE add-on that automatically does this everytime you save changes to a project file, or come up with some batch process that will just recurse over your source directories and clean up all the VBP's in one go.
The IDE seems to randomly change the
case of things; this seems to happen
frequently to project references.
Sometimes they are output in lower
case, and other times they are
output in upper case. You can get
around this by choosing "Ignore
Case" when you diff files in
SourceSafe.
Control coordinates, such
Top, Left, Height, and Width, can differ between
two revisions of the same form. This is due
to different developers using
different screen resolutions and/or
different screen DPI settings while working on the same form.
If you aren't doing this already, I
highly recommend that you get
everyone to develop using the same
resolution and same DPI setting.
The differing values are caused by rounding errors that
occur when logical screen
coordinates at different resolutions/DPI settings
are converted to twips, the default
coordinate space that VB uses for
laying out forms. Additionally, while I'm on the topic, make
sure everyone has their display set to 96dpi,
because if you develop VB forms at
120dpi, there is a really really good
chance they won't display correctly
on a display set to 96dpi.
There are probably other things I
can't remember right now...
As for the order of controls being changed in form files, this is normal, and you usually don't want to try rearrange the order of controls by hand if it happens to change from one revision of the form to the next. The order that the controls appear in a form file determines their Z-order on the form. If the order of the controls changes in the .frm file, this will change their relative Z-order on the form, which could lead to unintended results in how your forms are displayed.
Can you make the .vbp file read-only when you aren't editing it (ie, adding modules, etc)?
As far as form files...I can't think of any good way at all to make VB not reorder them. But I have to say that I've never encountered this before. Are you sure that something else isn't going on?
It's entirely possible that I just never paid any attention to this in the past, so I'm not saying you are mistaken, just offering my own observations.
I have noticed that re-opening the form and saving again often restores a consistent order.