|
| [WD21] Internal procedures - very disappointing! |
| Iniciado por guest, 07,oct. 2016 12:05 - 11 respuestas |
| |
| | | |
|
| |
| Publicado el 07,octubre 2016 - 12:05 |
Hi all,
I was rather enthusiastic to hear that Windev will -- at last! -- have internal procedures within procedures. After all, I had used them extensively in my good old Clarion Professional Developer days. In CPD they were called Routines. With Windev I have been forced to do without it them, which has made coding more difficult, slower and uglier.
The Internal procedure was one of the major "killer features", that urged me to "upgrade" from WD19.
Now I have tried to use them a few of times, and it has been very disappointing. The worst thing is that in the internal procedure you cannot use the parameters given to the main procedure! And this makes the internal procedures practically useless.
And when I combine to this the general worse quality and instability I have experienced with WD21, I feel that I have been badly cheated by PCSoft. My money was good, but their product is [beep].
Best regards
Ola |
| |
| |
| | | |
|
| | |
| |
| Publicado el 07,octubre 2016 - 15:12 |
| I don't understand what are you talking about. I use internal procedures and I didn't have problems with them. The internal procedure is usable only inside process in which it declared. All local variables declared in the same process (and in initial code of window) are visible for it. So what is you problem? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 07,octubre 2016 - 16:25 |
Hi,
I also use internal procedures without a problem !!
Could you give us example code of what you are trying to do ?
Danny |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 00:32 |
| Internal Procedures work great for me too. Post some code so we can see where your problem lies... |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 02:33 |
I am in the process of removing internal procedures. I have code that has worked fine for months. I have moved some code blocks into internal procedures to simulate top down structured programming techniques.
Upon moving the code into an internal procedure, it will randomly throw an error after running for hours and being called repeatedly. These errors have shown up in calls to hWrite(), API(), and procedures declared global to the whole project. In all cases the error indicates that an improper parameter was passed to the procedure. In many cases, but not all, these parameters are hard coded, not in variables. Again, it is not that the procedure will fail immediately, but after several hours where it has been called successfully and then suddenly fails. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 10:57 |
Hi all
The problem is the parameters given to the (main) procedure by reference. The (main) procedure's parameters cannot be used in the internal procedure (IP).
Of course you can first move the parameters to local variables and then use them in the IP, but that is an unnecessary complication.
So you cannot change the value of the parameters.
I haven't yet tested how it works, If I change a local variable in the IP and then move the local variable back to the parameter in the (main) procedure's code, but that would be another unnecessary complication.
It seems that the internal procedures are somehow handled differently from the main procedure's code. IMO they shouldn't. IP calls should be handled just like any other code in the procedure, for instance like the GOTO command, but with automatic return to behind the place where they were called from.
I don't see what are the benefits of blocking the use of the parameters in the IP other than complicating things? Maybe there are some? I'd like to know.
Example:
Procedure MyProc(parameter1) Blaah IF Parameter1 = Something THEN GosubIP1 ELSE GosubIP2 END Blaah Return Internal Procedure GoSubIP1 Blaah Parameter1 = Blaah //Creates error: "A parameter by reference cannot //be used in an internal procedure..."! Blaah END //Internal procedure 1 Internal Procedure GoSubIP2 Blaah Parameter1 = BlaahBlaah //Creates error: "A parameter by reference..."! Blaah END //Internal procedure 2
Best regards
Ola |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 13:37 |
Ola
Had not noticed this - just tried and found that what you say here is correct.
The issue however is always going to depend on your programming style I guess.
Checking through my Internal Procedures (I have 20+) I obviously found no instances where I had attempted to use the passed params - indeed I rarely pass params to a local procedure.
If, as you seem to be suggesting, I needed to update the params to return to the calling window I would use be using global variables on the window (or getters,setters if a class) to handle this. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 16:17 |
Hi DerekT
Yes, there are always ways to get done what needs to be done, but in this case they again are just workarounds, just complicating things. And of course there are simple cases where this limitation does not apply.
When I first tried the WD internal procedures, they all were cases where I needed to update the parameter, and I thought, what the... ...again just another half-baked feature added only to fill the sales brochure!
Best regards
Ola |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 17:53 |
Hi Donald,
to me this smells like a) a "memory leak" or b) a non-threaded and thus unprotected re-calling of a procedure in too short a time interval. Both maybe even caused by WD-code and not by yours. First I'd look whether memory usage is growing in order to be able to judge about the reason ... |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 18:43 |
I solved most of my problems by removing the Internal Procedures. I was not passing parameters, just moving sections of code into the internal procedures to structure the code better (in effect using them as a GOSUB). They were always calls to Windev procedures such as hWrite() and as I said only happened after several hours of use.
The API() problem was more difficult. And since the API was called in a loop perhaps 100 times per second, and was causing a GPF in the OS, I guessed that it was something like a memory leak. Again, this would happen about once every 2 hours.
I reduced the frequency of the calls by 80% and it did not help. I tried adding threadpause(1) and it made the code unusable. I changed the threadpause(1) to wait(1,waitmouseandkeyboard) and it seems to have solved the problem. I know that using wait() in threads is not recommended. But in this case it worked.
I know that PCSoft wants to increase sales in the US. However, the IT culture here is rather brutal toward products that do not have adequate QC or at least the availability of a list of known problems. Releasing features as production that eventually get fixed in releases two or three years later is not a good way to get market penetration here.
The calls to an external API may very well not be a problem with Windev. But Windev procedure call failures and the undocumented problems with passing of parameters should have been caught and at least documented in the help files before the feature was released. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2016 - 19:51 |
Except when Windows throws a GFE, the error message I am getting is shown below. The line of code causing this error is:
API(USBDLL$Name,"USBm_WriteB",BBDevice1,bb$$Svc)
Where USBDLL$Name and bb$$Svc are constants and BBDevice1 is an integer variable. The call will work for an hour or two and then throw the error. wd201vm.dll is always the Windev module throwing the error.
-------------------------------
08/10/2016 09:38:51:60 Program Restarted - Error Condition - GP_Error - Error Description Follows
WL call:
Process of 'Global Procedure GP_ButtonBlockThread' (GlobalProcedures.GP_ButtonBlockThread), line 45, thread 0
'API' function, syntax 0
What happened?
'
Error code: 2803
Level: fatal error
System error code: 127
System error message:
The specified procedure could not be found.
Dump of the error of 'wd210vm.dll' module (21.0.317.0).
Identifier of detailed information (.err): 2803
Debugging information:
Fonction (0,90)
Additional Information:
EIT_PILEWL :
Global Procedure GP_ButtonBlockThread (GlobalProcedures.GP_ButtonBlockThread), line 45
EIT_DATEHEURE : 08/10/2016 09:38:51
EIT_TYPE_WDFILE : <7>
EIT_IDCODE : <458752> |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,octubre 2016 - 07:04 |
I have gone through several testing loops to make my project more stable.
I have removed internal procedures.
I have added delays to loops in threads to slow down how fast they cycle.
I have reduced the calls the API procedures that write values so that they happen once every 10 cycles.
I have gone through the project and wrapped every api() call to the third party DLL in
WHEN EXCEPTION IN ...
DO
ExceptionEnable()
END
since it doesn't matter if the IO handled in the loop is delayed.
I have also wrapped an hWrite() call in the same type of exception code.
Each of these steps has reduced the frequency of exceptions causing a program hald. The last test lasted 6 hours and there were no API() call exceptions that weren't handled in the program.
I did add the hWrite() exception code as that one showed up after I had fixed the API() exceptions. Continuing to test, making progress. |
| |
| |
| | | |
|
| | | | |
| | |
|