Our PowerBuilder application is fairly large and has many objects in several PBLs for organizing our code. We often have 10 or more datawindows on one window, and these datawindows may be spread across two or three PBLs. For version control, we use exclusive check-out to avoid merge conflicts.
The situation is that when you right-click on a datawindow object from the Window painter you get a context-menu with options like "Script" and "Properties" and "Modify Datawindow...". We'd like to add one for "Check-out..." to avoid having to hunt for the datawindow in several PBLs.
Any ideas on how to do this, or something similar, would be greatly appreciated.
I think the best you can do is to create a temporary library at the top of your library list, locate your datawindows by jumping to them via "Modify Datawindow...", then saving them into your temporary library, and finally using the tools in your source control system to locate them by name and lock them.
One other trick that I use is to uncheck the tick box in the source control options that clears down the .srd etc files, then using your operating system's find tools to search on file name for these (since Powerbuilder still doesn't support searching for objects by name...). Of course if you don't have many objects, and if your objects don't have many references, you could always use Powerbuilder's search... but who do you know in the that fortunate position?!!
I think you've hit on a problem that a lot of people run into, which runs right through a loophole in PB that lets you start editing a DataWindow without warning you to check it out. Unfortunately, to the best of my knowledge there is no way to hook into the context menu.
However, you can hook into toolbar items. If that was the way I wanted to go, and I had plenty of time to spare, I'd write an app that I would launch from the toolbar, and here's what it would do:
Find the PowerBuilder window with APIs
Find the current sheet in PB
Get the object name out of the title
Get the current application (registry or PB.INI, depending on the version of PB, and may involve getting the workspace first, then the current target)
Get the library list (PB.INI or target file)
Do a LibraryExport() on the object that's open
Find all DataWindow controls (this may involve looking at ancestors to determine control types)
Identify dataobjects for these controls (again, you may need to look at ancestors)
Use LibraryDirectory() to get a list of all objects in all PBLs
Find the dataobjects' PBLs
Throw up a window listing the dataobjects and their PBLs
OTOH, if I had PBL Peeper (and, yes, this is biased advice), I'd
Launch the "PBL Peeper (Browse current application)" icon on my desktop (OK, that's a lie; I'd already have PBL Peeper open and would just switch to the Browse page)
Ctrl-Q (for QuickFind) and start typing the name of the object (if you pause, it will find a partial match on what you've typed)
Hit [Enter] once to accept QuickFind's selection
Hit [Enter] again to expand the object
Find the DataWindow control in question and RMB on it
Select "Go to Default DataWindow"
If it doesn't show the library and name in the microhelp (it's been a long time since I've released a version, and I can't keep track of what's in the released version), find the Up toolbar item to go up to the PBL
I know this doesn't achieve a checkout, but it does "avoid having to hunt for the datawindow in several PBLs". And, you can probably achieve this faster than my first suggestion.
Good luck,
Terry
The way I do it is to right-click and choose Modify DataWindow. When the painter opens you can just read the PBL from the title of the painter. Then close the DataWindow painter so PB will let you check out the DataWindow. For the more general case of locating an arbitrary user object, use Terry's PBL Peeper method.
You could separate the organization of PBLs used for development from those used for deployment.
As long as the PBL names don't conflict between the two views into the source code. The PBG files registered in source control won't clobber each other.
The downside is that when new objects are added or deleted, you will need to update both locations.
I would create a datawindow only PBL with all the related objects and put them in the same target. When I worked with that sub-system or report i could then check out all the objects in the same library.
Related
We are evaluating a project where eclipse should be extended in a way to enable more analysis on code changes. As these changes are already stored by eclipse in the local history, we don't want to save all data again in files on the system and are searching for a good way to efficiently build it on top.
More details:
Java files are changing multiple times in a lifecycle of a project. To build some statistics about developer habits, we want to store additional data as last time modified, username, some user input, and some more things. This data should be displayed in a compare view with annotations but should be a normal comparison view also.
We don't find any extension points or classes to extend, which could make this possible so we think asking here for help is maybe a try to find an answer/tip for our project.
Thanks to all in advance.
I found this properties editor that seems perfect, I have a lot of translations to maintain. I found this editor that seems to be able to handle all languages at the same time, which is perfect for me: https://github.com/essiembre/eclipse-rbe
I managed to install the plugin, but now I have to confess that I'm way out of my league. Stumbling around in the dark...
How to start it, how to use it?
Or is there a better way to maintain properties in multiple languages?
I also have to maintain an application with a multi language user interface.
First of all I also started the attempt to use eclipse plugins for editing Java resource bundles but I am also failed... :(
After some test's with different editors I decided to work with JLokalize.
My way of proceeding:
Step (Switch to the package explorer of your Domino Designer)
Step (Select a folder for export to file system, e.g. Custom Controls or XPages)
Step (Set filter types to *.properties)
Step (Finish the export to your filesystem (or a network file share, if someone else should do the translation work))
Open and edit the resource files with JLokalize
After finishing your translation work you could import the translated files (e.g. *_en.properties for files translated to english) in your application.
Is there a plugin that lets you manually add files to lists/categories? Something like Mylyn but manual and more files--kind of the way Gmail manages mail--a tagging system.
If I let mylyn manage my windows it actually closes them without any way to shut off (Something I absolutely cannot tolerate, I use my open windows to remind me of what I'm working on--my memory absolutely NEEDS the help)--on top of that it automatically adds files to lists just because that list happens to be open when I start doing something else.
I guess I'm thinking of a plugin that offers a different version of the "Package Explorer", one that is organized by task instead of by package hierarchy, and allows you to move files around at will.
...or is there a way to adapt an existing tool to do this (without actually moving the files around, of course!) Bookmarks don't seem to offer a "Grouping" but using a common first word for the description in my bookmarks may work... Any other ideas?
After messing with it a bit more, it looks like bookmarks might do what I want. It is possible to filter bookmarks by searching the subject string, so as long as I put tags in the subject string I can select a sub-filter and have it bring up all the relevant files for a given task.
I won't accept this for a while in case someone has a better answer (a plugin perhaps?)
I'm trying to integrate our Source Control(SourceAnywhere) with VS and are getting a lot of push back because of this one issue.
Almost every time we open some of our Windows forms using 'View Designer' it edits the file (* appears beside file name). Nothing has yet been changed, I've tried comparing the before and after files and they are exactly the same. If we have the solution bound it will check the file out, but even if its not bound it still 'edits' the file. When you try to check the file back in, it doesn't get a new version or anything.
I've done some searching and haven't been able to find any way to change this behavior.
This is a huge pain point for me as if someone already has the form checked out and someone else tries to open it, they just get told that it can't be checked out, and the form won't open. Or, someone who has no intention to edit the form, will now have the form checked out but hasn't made any changes.
Thoughts?
This usually happens when there are controls within the form that have "Dock" set. If the IDE feels it needs to resize the form, then those controls will also be resized, and all of that information needs to get re-written to the source file. In the case where you're editing a form named "Form1" this source file is not Form1.cs, but rather Form1.Designer.cs - try comparing that file with the version from source control.
Alternatively, move to a source control system that doesn't use locking by default (for example, Subversion) or disable that feature in SourceAnywhere. This will require users to manage merge conflicts, but allows multiple users to work on a single file at the same time.
I'm unfamiliar with Pocket PC development, but I have to make a few minor changes to an VS2005, Pocket PC 2003 Device application. One of the changes (which I thought would be trivial) is changing the text of app's shortcut, but I can't figure out where this text is set. The solution includes a setup project, so I'm looking for it in there, but I can't find it. I know it's got to be in there somewhere because building the setup project generates an AppSetup.inf file that contains the shortcut information.
This can't be that difficult. Surly I'm suffering from what my wife refers to as "male vision" when I can't find the bottle of mustard in the refrigerator that's right in front of my face. Where do I specify this text?
It depends on exactly how the shortcut is generated. There are generally 3 mechanisms that are used.
Via the CEShortcuts section of the INF. For this, it's the text before the first comma
Via copying an LNK file via the CopyFiles section of the INF. With this mechanism, you create a physical LNK file on the desktop that gets rolled into the CAB and it's copied like any other file. The name on the device is again the first string before the comma.
Via a programmatic call (usually to SHCreateShortcut) in a custom CE Setup DLL.
You'll have to figure out which is being used in your deployment scenario to know exactly what needs to be changed.
Thinking more about this, are you trying to simply find where in the Studio UI of the installer project to change the shortcut? If so, this MSDN article may help. What is very non-intuitive is that there are little icons at the top of the Solution Explorer that change the view of the installer, allowing you to see things like files, registry entries, etc. It may be that you simply aren't looking at the right view and you need to select a different icon. There are no menu items that do what these icons do, and they are hard to notice the first time you start using an installer project.
Well, as I suspected, it was right in front of my face. We'll call this project PDAProject. In the solution explorer, under the PDAProjectSetup project is an item labeled Primary output from PDAProject (Active). If I double-click on this item two panes appear in the code editor window. The one on the far left shows a folder tree labeled File System on Target Machine. Under this are three folders labeled Application Folder, Program Files Folder, and Programs Folder. When I click on the Programs Folder, the application shortcut appears in the pane on the right and I can modify its text.
I don't know why I was never compelled to double click on that Primary output from PDAProject (Active) project item even though that's how you open any class or form for editing. I kept right-clicking and opening the Properties. Maybe it's time to give up programming and take up basket weaving.