Tip: Change cut directory at "runtime"

As promised earlier I'll give you a few more tips on the things you can do with the XRKB.ini file.
One of the nice features is that you can make changes to the XRKB.ini file while Socrates are running. (I don't know if this is recommended usage by the Cincom Socrates team).

At my team we use the Cut command a lot; we cut .XRA knowledge modules to various folders depended on which branch of the project we're currently working on and we cut to running instances of our application.

The cut command remembers the location of where you did the last cut, so if you did a cut to c:\MyProjects\MyCuts\ the next time you cut a knowledge module, Socrates will suggest the c:\MyProjects\MyCuts\ folder as your cut location.

An investigation of the XRKB.ini file reveals this entry:

C:\TheFolder\WhereYouDid\TheLastCut

If we combine this information with the knowledge that we can make changes to the XRKB.ini file while Socrates is running, it opens up for a more dynamically way of controlling where to cut knowledge modules without navigating to the destination folder each time.

Let's create two copies of XRKB.INI; name them cut_to_projects_XRKB.ini and cut_to_current_branch_XRKB.ini, and place them at the same location as the original XRKB.ini. If you have installed Socrates with default settings it would be in C:\Program Files\Cincom\Socrates. (I recommend that you keep a backup copy of your XRKB.ini file somewhere safe.)

In the cut_to_projects_XRKB.ini file, change the lastCut entry to:

lastCut=C:\Projects

Similary for the cut_to_current_branch_XRKB.ini file, change the lastCut entry to:

lastCut=C:\CurrentBranch

Keep all other entries in the .ini files the same.

Now we just need a way to dynamically switch between the two new files. Create two .bat files; name them cut_to_projects.bat and cut_to_current_branch.bat.

cut_to_projects.bat:

copy "C:\Program Files\Cincom\Socrates\cut_to_projects_XRKB.ini" "C:\Program Files\Cincom\Socrates\XRKB.INI"

cut_to_current_branch.bat:

copy "C:\Program Files\Cincom\Socrates\cut_to_current_branch_XRKB.ini" "C:\Program Files\Cincom\Socrates\XRKB.INI"

These simple one-liners will copy one of the new .ini files into the original (or current) XRKB.ini file, where Socrates will pull the information of the wanted cut directory from. So before you want to cut a .XRA knowledge module the next time, just run the .bat file that will change your cut directory to the desired.

Bonus tip: You should not use the mouse to point-and-click to the cut command, instead use the built-in short-cut commands: Alt+F | U | RETURN

A warm welcome :-)

When I returned to the office after nine weeks (six spend backpacking in Thailand with wife and kids) of paternity leave (yes, that's the sort of things you can do in Denmark ;-) my colleagues had made the warmest welcome I ever received. This picture shows the entrance to APC Denmark yesterday morning:


There were Danish flags over the place, big hugs as I entered, and I got to use our managers parking spot near the entrance. To top this Susan even made cakes for our afternoon break :-)

I can't shake the feeling that they want me to do something in return, but it's sure nice to know you've been missed :-)

Thanks guys! Now I'll go back to work -- and promise that this blogs amount of smilies has been used for the rest of the year :-)

Tip: Killing multiple instances of Xrclient

Do you belong to the group of Cincom Socrates developers that presses F9 over and over to test your application, but forgets to close the Xrclient.exe instances?



Here's a tip for you: Install PsKill, open a command prompt and enter this command:

c:\>pskill xrclient

This will end (kill) all of your running Xrclient.exe instances -- instantly.

Note: I actually recommend that you don't run multiple instances of Xrclient.exe at the same time. Get in the habit of closing them after use.

Tutorial: Moving items between lists

A knights tale ...
Suppose you're creating an application to equip knights with armor and weapons equipment. One of the constraints is that a knight can only carry a certain amount of weight, so we're only allowed to let him pick three items.

In battle it's important not to rely on one fighting strategy solely so we will add another constraint: A knight can only carry one of each item.

Specification
So, we want to develop a user interface where the user can pick up to three items on a list, transfer those items to another list (the knights backpack), and when an item is added to our backpack it should disappear from the first list.

Dynamic lists
Let’s create two dynamic lists to hold the added items and the not-added items. We need to tell Socrates that the lists are dynamic, that’s done on the lists info pane, section Inference.

We could name the lists ItemsNotAdded and ItemsAdded.

Add the two lists to a dialog, dlg_Equipment:

Double-click in the OnEnter field of the dialog to let Socrates create an OnEnter procedure (dlg_Equipment_OnEnter):

We also need a list to hold the initial items a knight can carry. Create a list called KnightItems and add the following records to it:Locate the newly created procedure dlg_Equipment_OnEnter and add the following code to it:

@dim i:n

@rem Populate the dynamic list with the content from KnightItems
@for i = 1 to KnightItems.nValues
   @do ItemsNotAdded.addInstance(KnightItems.ItemName[i])
@next i

Now, when the dialog starts up it will populate the ItemsNotAdded list with the contents of the KnightItems list.

To test the application so far we just need to add a call to the dlg_Equipment dialog in the Main Agenda:

@do dlg_Equipment

Move equipment from one list to another
Ok, now it's time to do the fun stuff :-) To move the knights equipment from one list to another we need two buttons; one for moving and one for re-moving.

Add them to the dialog:

Create a procedure prc_addEquipment and set the move button to activate this when clicked. Add the following code to prc_addEquipment:

@dim nSelectedIndex:n

@rem Only three items is allowed
@if ItemsAdded.nValues < 3
      @rem Only do this if something is selected
      @if ItemsNotAdded.nSelected = 1
         @assign nSelectedIndex = ItemsNotAdded.selectedIndex
         @rem Move it!
         @do ItemsAdded.addInstance(ItemsNotAdded.ItemName[nSelectedIndex])
         @do ItemsNotAdded.delInstance(nSelectedIndex)
      @endif
@endif

Similar, we'll create a procedure for removing equipment and let the Remove button activate that on the click event, prc_removeEquipment:

@dim nSelectedIndex:n

@if ItemsAdded.nValues > 0
   @if ItemsAdded.nSelected = 1
      @assign nSelectedIndex = ItemsAdded.selectedIndex
      @do ItemsNotAdded.addInstance(ItemsAdded.ItemName[nSelectedIndex])
      @do ItemsAdded.delInstance(nSelectedIndex)
   @endif
@endif

@rem Remove the pointer to "shadow" entry on list
@clear ItemsAdded

Press F9 and test the application:


Conclusion
With two dynamic lists we showed it was relative easy to make an application where items where moved back and forth from list to list.

Tip: Default user name

If you’re working in a multi user environment you might have noticed that when you’re prompted for a user name at login time it’s set to “Admin” as default. Wouldn’t it be nice if the default user name was your user name?


The default behavior of the login screen is controlled by the XRKB.ini file (default location is c:\Program Files\Cincom\). Locate XRKB.ini and open it in a text file editor (e.g. Notepad). It will look something like this:

[Main]
serialno="555-YOUR-SERIAL-NO-555"
username="YOUR-INSTALL-USERNAME"
showtips="1"
currenttip="10"
left="1"
top="1"
width="1389"
bottom="1043"
state="2"
lastcut="C:\projects"
lastsearchstring="Bicycle"
appinfopage="3"
expandedgroups="-204,2,3,4,5,6,7"
user="Admin"

export="C:\projects\"
import="C:\Temp\"

true="Yes"
false="No

Note the entry at the bottom of the Main section; user=Admin. This is where the default username in the login screen are read from. Change it to User=YourUserName

Save the XRKB.ini file and restart Socrates. The login screen will now look like this:

In coming articles will dive a bit deeper into the content of XRKB.ini and how we can benefit from modifing it dynamically (at run time).