Home
>
WinDev Forum
>
Topic
[WD24] Groupware fails to load all the project windows
Posted by Al
|
[WD24] Groupware fails to load all the project windows August 16, 2019 04:34PM |
Admin Registered: 5 years ago Posts: 297 |
Hello
In V22 I am using the old style groupware from V17. As part of my investigation into converting to V24 I am looking into the latest version of the groupware.
The infinite monkey theorem states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type any given text, such as the complete works of William Shakespeare.
I am convinced that same monkey was employed by PCSoft to write the code for the groupware.
It works, but what a mismash of programming methods and the overall premise was obviously to use the most complicated method possible as it is a nightmare to decipher.
Anyway the problem I have is that it creates a looper containing a picture of each window in a looper. It also tries to add the reports into the looper. I have dropped off the reports section as there are 900 of them, but I can't add more than 700 windows into the looper before Windev crashes and I have nearly 1300 windows in the project.
I can't see that it is a computer RAM issue as I have 32gb in my dev computer and with 700 windows the RAM usage is only 8gb.
There must be a limit of some sort in the looper. The short answer, which I haven't tried yet, is to try the process without loading the pictures, but I would like to try and find a solution that keeps them if possible.
The original code used threads to build the looper, one for images and one for rights and I have removed the thread process and just run the procedures normally.
Any thoughts much appreciated.
(Note: Removing the images works and all 1300 windows load so I will just remove the looper and replace it with a table)
Regards
Al
Edited 1 time(s). Last edit at 08/16/2019 04:54PM by Al.
In V22 I am using the old style groupware from V17. As part of my investigation into converting to V24 I am looking into the latest version of the groupware.
The infinite monkey theorem states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type any given text, such as the complete works of William Shakespeare.
I am convinced that same monkey was employed by PCSoft to write the code for the groupware.
It works, but what a mismash of programming methods and the overall premise was obviously to use the most complicated method possible as it is a nightmare to decipher.
Anyway the problem I have is that it creates a looper containing a picture of each window in a looper. It also tries to add the reports into the looper. I have dropped off the reports section as there are 900 of them, but I can't add more than 700 windows into the looper before Windev crashes and I have nearly 1300 windows in the project.
I can't see that it is a computer RAM issue as I have 32gb in my dev computer and with 700 windows the RAM usage is only 8gb.
There must be a limit of some sort in the looper. The short answer, which I haven't tried yet, is to try the process without loading the pictures, but I would like to try and find a solution that keeps them if possible.
The original code used threads to build the looper, one for images and one for rights and I have removed the thread process and just run the procedures normally.
Any thoughts much appreciated.
(Note: Removing the images works and all 1300 windows load so I will just remove the looper and replace it with a table)
Regards
Al
Edited 1 time(s). Last edit at 08/16/2019 04:54PM by Al.
|
Re: [WD24] Groupware fails to load all the project windows August 17, 2019 08:14AM |
Admin Registered: 5 years ago Posts: 501 |
Hi Al,
I spent quite a few days with Groupware of v15 and older. Tried to understand it, tried to remove some bugs and to add a few features. One of the problems is the Groupware analysis because one cannot have two analysises open at the same time, the project's analysis AND the Groupware's analysis. I never succeeded in moving the internal component "Groupware" with all of its features into a project's analysis. I decided to have my own "Groupware" and I wrote it.
- Users of my programs easily can switch from HFSQL Classic to HFSQL C/S. Groupware has to switch with it. Switching happens on basis of a HF7-connection, not on a simple HOpen(..)
- Administrators should be able to switch off Groupware completely while they would have the choice of using the protection of an admin-password for a few windows, especially those who're dealing with Groupware and sensitive data.
- Users and admins should be able to change their own password (= hash") - if the user's data allow for doing so. Only the logged-in user/admin can change the password.
- encryption of passwords is not good enough anymore and therefore is "old school". Hashing is the way to go. Salting the hashes is even better. See: https://crackstation.net/hashing-security.htm
- I wanted to record the computer's name and the IP-address of the log-in.
- I wanted to know not only the log-in time but the log-out-time as well. A session-GUID does the trick. If the main window is closed without log-off then the Groupware's History file will be either empty or record an abnormal log-out.
- I wanted to unify the naming mix of "Admin" and "Supervisor" in PCS Groupware. "Supervisor" is Novell Netware slang while Microsoft is using "Administrator". I decided to go with admin.
- Since our programs are used by rather small audiences, maximum user count is about 50, so I happily left the complicated rights theater (in PCS Groupware a user can be member of several groups with different rights). Our users are rather simple-minded and wouldn't understand that anyway. A user is member of a group and the group has a number of rights, that's it. Administrators are members of of the admin-group and cannot be restricted in their rights. I neither need Windows authentification nor that of an Active Directory.
- I started out with rights management down to the control level but soon found out that handling such a diversity is no good for our customers, they simply don't understand the hidden complexity of the concept. This led me to let them stop unwanted access at menu-level only.
- Theoretically, Groupware should be usable in Java, Universal Windows 10 Apps etc too. The claim of platform-independency stops with WINDEV Java applications already. Ok, ok, my Groupware is for Windows apps only.
Kind regards,
Guenter Predl
office@windev.at
Edited 1 time(s). Last edit at 08/17/2019 09:33AM by gpredl.
I spent quite a few days with Groupware of v15 and older. Tried to understand it, tried to remove some bugs and to add a few features. One of the problems is the Groupware analysis because one cannot have two analysises open at the same time, the project's analysis AND the Groupware's analysis. I never succeeded in moving the internal component "Groupware" with all of its features into a project's analysis. I decided to have my own "Groupware" and I wrote it.
- Users of my programs easily can switch from HFSQL Classic to HFSQL C/S. Groupware has to switch with it. Switching happens on basis of a HF7-connection, not on a simple HOpen(..)
- Administrators should be able to switch off Groupware completely while they would have the choice of using the protection of an admin-password for a few windows, especially those who're dealing with Groupware and sensitive data.
- Users and admins should be able to change their own password (= hash") - if the user's data allow for doing so. Only the logged-in user/admin can change the password.
- encryption of passwords is not good enough anymore and therefore is "old school". Hashing is the way to go. Salting the hashes is even better. See: https://crackstation.net/hashing-security.htm
- I wanted to record the computer's name and the IP-address of the log-in.
- I wanted to know not only the log-in time but the log-out-time as well. A session-GUID does the trick. If the main window is closed without log-off then the Groupware's History file will be either empty or record an abnormal log-out.
- I wanted to unify the naming mix of "Admin" and "Supervisor" in PCS Groupware. "Supervisor" is Novell Netware slang while Microsoft is using "Administrator". I decided to go with admin.
- Since our programs are used by rather small audiences, maximum user count is about 50, so I happily left the complicated rights theater (in PCS Groupware a user can be member of several groups with different rights). Our users are rather simple-minded and wouldn't understand that anyway. A user is member of a group and the group has a number of rights, that's it. Administrators are members of of the admin-group and cannot be restricted in their rights. I neither need Windows authentification nor that of an Active Directory.
- I started out with rights management down to the control level but soon found out that handling such a diversity is no good for our customers, they simply don't understand the hidden complexity of the concept. This led me to let them stop unwanted access at menu-level only.
- Theoretically, Groupware should be usable in Java, Universal Windows 10 Apps etc too. The claim of platform-independency stops with WINDEV Java applications already. Ok, ok, my Groupware is for Windows apps only.
Kind regards,
Guenter Predl
office@windev.at
Edited 1 time(s). Last edit at 08/17/2019 09:33AM by gpredl.
|
Re: [WD24] Groupware fails to load all the project windows August 18, 2019 06:41PM |
Admin Registered: 5 years ago Posts: 297 |
Hello Guenter
I finally got the current version groupware to work.
I had to re-write portions of the following procedures so that I could read in the older version data.
bMigrateAssociationsGroupsUsers
bMigrateGroups
bMigrateRights
I am allowing for the fact that we all have our own coding preferences, but the code in the Win_GPU windows and procedures is over complex and appears to be designed that way to discourage users to modify it.
I will follow your example and write my own process at some point in the future.
Regards
Al
I finally got the current version groupware to work.
I had to re-write portions of the following procedures so that I could read in the older version data.
bMigrateAssociationsGroupsUsers
bMigrateGroups
bMigrateRights
I am allowing for the fact that we all have our own coding preferences, but the code in the Win_GPU windows and procedures is over complex and appears to be designed that way to discourage users to modify it.
I will follow your example and write my own process at some point in the future.
Regards
Al
|
Re: [WD24] Groupware fails to load all the project windows August 19, 2019 06:22AM |
Admin Registered: 5 years ago Posts: 501 |
Hi Al,
PCS programmers use the same coding style throughout all of their products. An overwhelming bunch of procedures. There is a school somewhere in the world that says that a procedure should not contain more than 10 LOCs (lines of code). They are following this rule. Be happy: OOP is even more difficult to read & understand.
Kind regards,
Guenter Predl
office@windev.at
PCS programmers use the same coding style throughout all of their products. An overwhelming bunch of procedures. There is a school somewhere in the world that says that a procedure should not contain more than 10 LOCs (lines of code). They are following this rule. Be happy: OOP is even more difficult to read & understand.
Kind regards,
Guenter Predl
office@windev.at