I have a system that allows users to create multiple diagrams. I want to be able to copy a part of one diagram, close it, run another and paste in what I have copied. The problem is that the diagram.copy() and diagram.paste() functions use an internal clipboard which is lost when I close the original diagram, so there's nothing to paste when I open the other one.
I'm very new to Telerik, so I don't really know how to approach this. I tried digging through the documentation, but I couldn't see any way to interact with the internal clipboard other than the two functions.
Preferably I'd like to be able to read the internal clipboard, copy it to a global variable and then read the variable back when opening the destination diagram.
Or maybe there's a way to read the selected shapes into a variable without using the copy() function?
Reading the source code, I've found it's stored in the variable diagram._clipboard . You can run this sample and inspect: https://dojo.telerik.com/onunEkib
However, as an undocumented feature, this can change and break when upgrading your Kendo version. Plus, as this is the diagram's internal data, it can be invalid for the target diagram.
What I'd do is a custom copy button that gets the current selection through the select method.
Related
I think the answer to this will be "no" but it doesn't hurt to ask - and get people thinking.
I'd like to be able to programmatically add VBA as a text string to a PowerPoint presentation I'm creating with python-pptx.
I know I can confect the XML to create a button that, when clicked, runs a macro that already exists in the .pptm file.
Because the macro is stored compiled I don't think I can inject it as text programmatically. (I checked the format of a .pptm file with a "Hello World" macro in and there is an extra file in it with non-text material in.)
I also don't know if I can write a .pptm (macro-enabled .pptx) file with python-pptx.
So, Has anyone experimented with this?
The best I think I might be able to do - in md2pptx - is allow the user to add buttons that call pre-existing macros in the template file when clicked on. Unless the user builds their own template file off one I supply I don't think that enables me to add general function (such as deleting the first slide or note taking).
So I'm writing a script to modify quickly a VB6 application's interface with COM controls. (Created in C# .net). Most of it works fine, but some panels are giving me a lot of trouble.
Basically, I open the .frm file and read it, and when I find some controls I modify their values or insert new things. When I find a panel, I create a different panel around it so it looks better. I'll put, say Top = 2340 in the file for my new element. If I open the .frm in notepad, I can clearly see that the value of Top is at 2340. Once I open VB6, the panel's top value is at Top = 8190. It also modifies the Left value, but nothing else. If I save and exit vb6, then reopen the .frm in notepad, the Top value will be saved at 8190.
Why does VB6 uses different values than the ones in the .frm file? Is it trying to avoid elements stacking on top of each other ? What is happening between reading the file and opening it, that forces a different value of the Top property?
Just a theory, but I believe the issue is that the ScaleMode property isn't setup right. By default, unless the container window has the property, it'll be set to Twips. So what may be valid under certain containers won't be valid in other containers.
The MDIForm container, for example, forces Twips, and may even re-position objects based on alignment.
If this is the form itself, which I don't think it is but worth mentioning, make sure the StartUpPosition is properly set to 0 (Manual).
We have an in house button control, and quite frankly it sucks. I'd like to replace it but I don't want to go onto every form in our project and delete/add a new control. It seems to me that if I design a new button that has all the same properties as the old one then I ought to be able to give it the same name as the old one and just replace all the reference lines in the vbp files to point to the new control.
Has anyone tried this (better yet have you heard of a tool that will do it for you) and if so what 'gotchas' should I be on the look out for?
Thanks!
The *.vbp files are one place you'll need to change. There are also references to the used control libraries in the files containing GUIs -- that's form (*.frm), control (*.ctl), and property page (*.pag) files. These files are in a plain text format and you can see the references at the top. They look like this:
Object = "{831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0"; "mscomctl.ocx"
Those refs will need to be added or updated in all relevant files if the new control is a compiled OCX. If it's in the same project I don't think it needs any reference there, and if it's in a different project in the same project group I'm not sure. Save a test form with the new control to see.
Note that you don't have to keep the same control class name. Inside the *.frm/ctl/pag files, instances of individual controls on them are represented by a simple format like this:
Begin VB.CommandButton Command2
Caption = "Cancel"
Height = 375
Left = 2460
TabIndex = 1
Top = 2400
Width = 1455
End
The syntax of the first line there is "Begin LibraryOrProjectName.ClassName NameOfThisInstance". So, provided the offending control's name is distinctive it should be easy to search & replace references to it both in the BASIC source and in the GUI layouts. You might want a plain text editor that can perform search and replace across multiple files (Notepad++ is one).
Some control properties are stored like this:
Picture = "frmMain.frx":292F
These correspond to the *.frx, *.ctx, and *.pgx files, which contain binary data for the values of certain control properties. I don't think these files should need altering or cause any problems. They don't appear to contain control names.
Use a full compile (Ctrl+F5) to be sure no problems linger in parts of the source afterward.
Never tried it. Good luck.
There is only one tip to be added to the accepted answer.
If you need to replace any generic VB control with 3rd party or custom ActiveX control you must replace the:
BeginProperty Font
with
BeginProperty Font {0BE35203-8F91-11CE-9DE3-00AA004BB851}
Omiting to do so results with run-time error 713 when trying to edit/open the form.
If there is no BeginProperty statement in the block then control uses default font and this replacement is not needed.
An additional scenario to look for is if the classes in the OCX are referenced directly in code.
In other words, if the control class was ABCButton then you need to look for ABCButton in all .BAS and .CLS files as well, and make appropriate changes.
I have to maintain a large MATLAB GUI, containing quite a few callback functions, each of which gets called at many points. At some point, I decided to rename one of the callbacks; in order not to have to go through GUIDE to manually modify each of the UI that calls it, I used the excellent gencode program to "unwrap" the .fig file, s/old_name/new_name/g, and recreate the .fig.
This seems to work well, except for one thing: when clicking on a button in a button group, I got a message telling me that the function manageButtons is unknown. After a bit of googling, I find that manageButtons is a nested function in childAddedCbk, which, I assume, is called by GUIDE as the GUI is created. Now, trying to move just manageButtons outside to its own, in-the-path file doesn't work either: the hgroup passed to it is an invalid handle object.
So... does anyone has a workaround for that? Any of the following will be appreciated:
changing all the callbacks in a GUI in a semi-automatic way, or
making the manageButtons get a valid handle, or
having gencode not break all that.
Thanks,
Antony
You can export the FIG + M file to single .m file. You will lose the ability to edit this with guide, but you will be able to do a simple regular expression replace on the resulting .m file.
In order to do so - use on the menu of GUIDE -> File -> Export.
I want to browse a directory where many Matlab GUI's (.fig files and their related .m files) are stored and change them systematically. For each, I want to search for a certain popup menu and, if it exists, delete some specific options.
I usually use get() and set() or similar functions to fiddle with GUI's, but these functions require handles, and I don't know how to get handles when not running the GUI, and also I wouldn't know how to save the changes.
If I open a .fig as text it is unintelligible.
I'm considering opening each at a time in guide (Matlab's GUI development environment) and changing it manually, but really would like to avoid it. I'm talking about tens of files, and my action might have to change in the future.
Maybe there would be a way to control guide from the command line? Or another solution?
You can load the .fig files using hgload or openfig. Both these functions return the figure's handle.
Once you have the figure's handle you can use findobj to get the popup menu's handle. Then set and get as normal to change the menu's options, and then save the modified figure using hgsave.
For example:
f = hgload('file.fig');
menuH = findobj(f, 'Type', 'popup');
set(menuH, 'String', new_options);
hgsave(f, 'file.fig');
gcf() immediately after open() gets the handles and can be done programatically for many figures.