How to make it impos. in MDI, to open a appl.-part twice ?

[ukoenig]

Hello,

Is there another way to make it impossible,
that a user can open a application-part twice in MDI ?

In the moment my solution works like :

1.) I start a part from a office2007-bar ( oBtn1 ).
2.) Before i open the dialog i disable the office-bar-button.
oBtn1:Disable()
( the user cannot open twice the same part )
3.) After closing the dialog, i enable the office2007-bar-button again.
oBtn1:Enable()

It works, but is there another way how to do it ?

Best Regards
Uwe

[xProgrammer]

Hi Uwe

Some possibilities might be:

If you are using OO / CLASSes you could use a CLASSDATA property to keep track of this. Even if you aren't you could create a CLASS specifically for this purpose. You may not have to use CLASSDATA if you ever only instantiate one instance of the class.

You could of course use a PUBLIC variable(s) - but using a CLASS would be neater in my opinion.

The above of course assumes that you don't need to stop the user starting up a second instance of your software and being in the same part in that second copy. That may or may not be a problem. If it is you presumably need to use a file locking methodology based on your user logon.

If you have lots of parts you would probably want to standardise access control in a single function - maybe a hash array would be the easiest - each part would have its own hash key which it could pass to this access control function.

Happy to discuss any of these ideas more with you if any are of interest. Clearly details would depend on the way your application is structured.

Regards
Doug
(xProgrammer)

[ukoenig]

Thank you very much for the answer,

There was the problem as well, to open a 2. instance of
the software ( i dont want it ).
This problem is solved ( a toppic some days ago ).

Maybe when only 1 instance is running, it might be
the best solution, to disable the button, who starts
the appl.-part. Then the user can see on screen,
because of the disabled button, the part is already running.
It also could be, that there are still other parts, you dont want
run together with the activated part.
The problem is, the users sometimes just click around
and you might loose control, whats going on.

So maybe like i have done before,
on top of a dialog : disable all buttons i don't want
to be activated and after closing the dialog,
activating the buttons again might be the best solution ?

Best regards
Uwe

[xProgrammer]

Hi Uwe

It certainly should work and give the user an indication of what they can and can't do. However it doesn't explain why. The alternatives would presumably be to either:

a. display a message indicating that they already have this part running or

b. set the focus to this part that is already running

Option a could possibly give the user the option to set the focus as per option b or maybe, if appropriate, kill off the existing copy of this part and start a new one?

I'm not saying that either of these options are necessarily any better or worse. Merely that they would seem to be the available alternatives that you may wish to consider knowing how your application works and the nature of the users of your application.

Regards
Doug
(xProgrammer)

[James Bott]

Uwe,

Your problem is just one of the reasons I stopped making MDI apps and now only make SDI apps.

Below is from my notes. This may be the answer to your question.

Regards,
James

-------------------------
Checking for MDI child windows

If you need to check for MDI child windows you can look at oWnd:oWndClient:aWnd which is an array of MDI child windows objects.

You can check the captions:

oWnd:oWndClient:aWnd[1]:cCaption

See \carrot\common\ordWndCount() for an example of counting the number of a certain type of MDI windows that are open.

Here is a function to prevent opening more than one copy of a MDI child window. It also brings the window to the top and set the focus to it.

Code: Select all | Expand

//--- Sets focus to child MDI window with cTitle
static function wndSetFocus(cTitle)
   local i:=0,lSuccess:=.f.
   cTitle:=upper(cTitle)
   for i=1 to len(wndMain():oWndClient:aWnd)
      if upper( wndMain():oWndClient:aWnd[i]:cCaption )=cTitle
         wndMain():oWndClient:aWnd[i]:setFocus()
         lSuccess:=.t.
      endif
   next
return lSuccess

Then you can do something like this for a menu or button:

...ACTION if( ! wndSetFocus("Order"), TOrder():new():browse(),)

[xProgrammer]

Hi James

Nice, But it does assume titles are invariate which mine certainly aren't. For example for a patient record my title would be along the lines of:

Edit Patient BOTT, James DOB 24.12.1980 [0012765]

So small additional data structure required in such cases,

Nice to "talk" to you again

Regards
Doug

[James Bott]

>Edit Patient BOTT, James DOB 24.12.1980 [0012765]

In your case you could use "Edit Patient" as cTitle.

James

[xProgrammer]

Hi James

Forgot that. Silly really after so many years of xBase (although there was a long gap until recently)

Thanks for reminding me

Regards
Doug

[nageswaragunupudi]

In those very rare occassions when I want to restirct the user from invoking the same mdichild more than once, I use the code similar to below. I have this template and use it with appropriate modifications.

My template:

Code: Select all | Expand

#define DISABLE_CALLINGITEM
// above define is used when we want to disable 
// invoking button or menuitem


function MyMDIChild( oItem )       // oItem is required if we want to disalbe the invoking menuitem / button

   static lRunning := .f.
   
   local oWnd
   local lMenuDisabled := .f.
         
   if lRunning
      if oWnd != nil
         if isIconic( oWnd:hWnd )
            WndMain():oWndClient:ChildRestore( oWnd )
         endif
         WndMain():oWndClient:ChildActivate( oWnd )
      endif
      return nil
   endif
   
   lRunning := .t.

#ifdef DISABLE_CALLINGITEM

   if Valtype( oItem ) == "O" .and. ;
      Upper( oItem:ClassName ) $ "TBTNBMP,TMENUITEM"
      oItem:Disable()
      lMenuDisabled := .t.
   endif      

#endif
   
   // other code
   DEFINE WINDOW oWnd MDICHILD OF oWnd 
   // other code


   ACTIVATE WINDOW oWnd ;
      VALID ( If( lMenuDisabled, oItem:Enable(), ), lRunning := .f., .t. )
      
return nil
      
//----------------------------------------------------------------------------//

// To avail the functionality to disable/enable
// the calling buttons ( if that is what we want )
// menu / buttonbar buttons should be coded like this

   MENUITEM "MyMdiChild" ACTION MyMdiChild( oMenuItem )
   
   DEFINE BUTTON OF oBar ACTION  MyMdiChild( This )
   
//----------------------------------------------------------------------------//

If we adopt the above code, without disabling the invoking control, then when user clicks the menu/button second time, the mdi child is restroed and made active if it is not.

[ukoenig]

Thank you very much everybody.

A customer of mine wanted a special Password / Login-system.

It is very nice, because on each workstation
you can only see the buttons of the appl.-parts
belongs to the user-password.

Connected to each password, is a value.
As a sample :
value 5 is the highest and belongs to the supervisor.
Value 1 is the lowest and the user can input only some data.
Each value contents informations about appl.-parts can be opend.
As soon, a user loggs in with his password,
the system shows only the buttons belongs to the password.

Maybe the source is interesting for some programmers,
if they want to handle a system like this ?.


Best Regards
Uwe

[James Bott]

Uwe,

I do that by building the menus and buttons based on the user rights after the user has logged in. Is that what you are doing?

James

[nageswaragunupudi]

Uwe,

I do that by building the menus and buttons based on the user rights after the user has logged in. Is that what you are doing?

James

Yes.
It is quite usual that we make applications to behave appropriate to the logged in user's rights and roles, including even the dash boards ( start up screens ), etc and enabling / disabling or making visible./invisible some menus / buttons is a small part of the entire design

[ukoenig]

Hello James,

that is exactly what i mean,
i don't know, if it is useful to put a complete
sample in the forum, starting with password
and disable / enable functions at prog.-start.
Maybe some small drawings as a documentation included.
It may be helpfull for the beginners.

Best Regards
Uwe

[James Bott]

Uwe,

>and disable / enable functions at prog.-start.

Hmm, disabling menu items and buttons is different than not defining them. I don't want users to see disabled items--they won't know why they are disabled and will try to figure out how to enable them. Also, I think that it is better for users to not know that they may not have access to some parts of the program. If they know, then they feel left out--kind of like second-class citizens.

I do something like this when defining the menu:

Code: Select all | Expand

   if oUser:level >= 3
      meunu item ...
   endif

This way the menu item is only defined for users with level 3 or greater.

James

[xProgrammer]

Hi all

In the past I have taken James approach - user logs in and the contents of the menu is built based on the user's profile. In some instances the user's profile for a given entity (for a large organisation comprising multiple entities). As James said it reduces user complaints that they aren't given access to items that appear on their menu disabled.

Design should cope beyond controlling access to a "screen" to also enable level of access. For example some users may have read only access others can update. Some users may not get certain fields. A common example is cost price. In a clinical setting (eg hospital) celebrities may get booked in under a false name but trusted employee in accounts department needs to see the real name and account details.

Also, particularly for larger organisations, where jobs are generally more specialised, you may want to have initial screens based on user login. Plus you will probably want to introduce the concept of user roles or groups - so that there is less work in setting up a user profile.

It can get more complex than this. Take a hospital as an example. A nurse may have special access rights to patients on the ward she is working on, a doctor to patients he has admitted or have been co-referred to him. Access outside this may be denied or allowed but reported.

Have fun
Doug
xProgrammer