Jump to content
Server Maintenance This Week. ×

Go to related record when using modules


This topic is 6982 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I am looking for some good ideas about how to handle the 'Go to related record' when using modules based in the separation model. My problem is that I have a CRM System which has a data and interface file and that I have a studio system that has an data and interface file. All has been going well with development until I want to link a client to a studio record and use a button to link back to the client record. What happens when you use the 'go to related record' is that it goes to the data file and while I could load this file with scripts to seach and display this record in the interface file, I would rather not if there was another way to do this??? I have tried the window options, without success. Any ideas would be much appreciated.

Perhaps the separation model was not the best idea for a solution that will end up in modules?

All thoughts gratefully received on this subject.

Link to comment
Share on other sites

I'm actually working on a large module based solution. While go to related is convienent it obviously does not work in this paradigm. If your solution is not large, diverse or being worked on by multiple developers at the same time - you may want to toss the module concept at this time. We're keeping ours for the time being.

If you do decicide to keep them ~ I've installed a few scripts in my data files to forward me on to the right interface/record. Not too much work and once they're in you can re-use them from many different modules - think of them as your basic, core navigation scripts.

Link to comment
Share on other sites

Thanks guys, yes tried the external tables, but they are still in the data file not the interface file. I think by the sounds of this I will have to navigate through scripts which is a whole lot more work... I want to keep the module based solution as it makes it easier to customise further solutions without giving the client everything at once, also there is more than one developer, but at least you have confirmed my suspicions and I am glad that I have not missed something simple!

Thanks again

Link to comment
Share on other sites

  • 4 weeks later...

I've applied the seperation model to a complex database solution and I found this problem to be a continual stumbling block. The problem arises, as you mentioned, when there is more than one layout file, e.g. to increase the modularity of the solution. If the data and layout are not kept together then you can't use the "Go to Related Record" script step to hop from one layout file to another.

My (suboptimal) solution is to create my own "Go to Related Record" scripts in both the source and the target layouts. This source layout calls the script in the target layout and passes related data as script parameters. The target layout script performs a find using the script parameters. However, this really does not mimic the behavior of a "Go to Related Record" script step, because there is no option to "show only related records" which maps the current found set in the source layout to the matching files in the target layout. If you pass specific parameters you will end up with only one related record in the found set.

The preferred solution, of course, would have the "Go to Related Record" provide an option to select a layout in a separate file.

Link to comment
Share on other sites

I have been providing all the layouts used in the interface in the interface file. All the layouts used in the BR in the BR file. I use a standard layouts in the data file. If the layout is not seen by the user, I use a blank layout, sometimes I add fields so I can check my scripts.

Link to comment
Share on other sites

I haven't had that experence yet. I think that if you had 2 interface file you might also have 2 BR files. The data files being the only common link. The reason to have 2 interface files that would interact escapes me.

Link to comment
Share on other sites

  • 2 weeks later...

Multiple layout files are practical if you have a very large number of layouts or want to preserve the modularity of the data, database logic and layout files as a well defined package yet provide the ability to data to interact and allow the user to navigate between them (e.g. Patient Demographics, Clinical Results, Freezer Inventory).

Link to comment
Share on other sites

  • 1 month later...

I am having a similar problem. I am attempting to learn FM while converting to FM7 and also while trying to separate data and layouts. I've reached a roadblock here with trying to use GTRR ... and it keeps bringing up a layout in the data file. I'm not sure if I follow the entire thread here, but are you saying that if the layout I want was part of the same UI file that I would not have a problem? I would like that BUT I don't know of an easy way of copying layouts from one file to another. Is that possible? Otherwise, re-creating this would be a major undertaking.

Link to comment
Share on other sites

This is probably common knowledge but I discovered that it is not that difficult to copy a layout into a new interface file. Contrary to what I had been led to believe from other posts, all that it is necessary to do is to do a Select All in the layout view of the form in the first interface file, copy the selected fields, create a new blank layout in the target interface file, and then paste the selected fields into the blank layout. Since I had previously defined the table occurrences in the target file all fields had correct references. Voila!

Link to comment
Share on other sites

This topic is 6982 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.