Recent content by Stefan

Renato, another account that was created nearly ten years ago has been woken up and put on spam duty. There are about ten accounts signing up to this forum every day. Of those ten, nine are obvious spam bots directly selling their goods on their profile, the others - are probably sleepers like...

Today a spambot that had been dormant for TEN years was activated and posted a first spam post. Grabbing some popcorn to see what exciting offers will be presented this weekend.

Sure, but very large related to 15 thousand members? Doubtful. The spam (sleeper) accounts are easily identified by various criteria: - join date = last visit date - join date and last visit date are at most a month apart - zero posts - member profiles with hyperlinks containing escort or keto...

Luckily the spam hits the posts not too often, but hurray, let's welcome hotty new member Eisha - this new member spam stream is constant. This site has 15 thousand members. I doubt that even 5% is real.

Check new profile posts and the members... and pfff what a spambot mess, maybe its time to close progresstalk.com down? You really need some moderation tools, first seen and last seen within a week -> delete. I think you will be left with less than 1% of the current "members".

Are there moderation tools for approving new users / first posts?

Regarding the docs, I am not sure if archive.org has archived all the pdfs, but they have the Progress 9 landing page.

The only thing you need is to add the somewhat counter-intuitive delete object ophDataset to the end (or finally block) of procedure B. The delete is postponed until the procedure ends. See first note of DELETE OBJECT statement:

No.

1. The WebClient executables are available at WebClient Executables - Progress OpenEdge 2. with 12.8 the classic AppServer is no longer supprted, you must use PASOE - Quick Start: Moving Your Classic AppServer Applications to the Progress Application Server for OpenEdge

This abomination will give you named run-time arguments :-) /* parent.p */ RUN child.p 'cArg' 'Teststring' 'iArg' 123. /* child.p */ &if '{1}' = 'cArg' &then &scop cArg '{2}' &elseif '{3}' = 'cArg' &then &scop cArg '{4}' &endif &if '{1}' = 'iArg' &then &scop iArg {3} &elseif...

Even without preprocessor magic, a single include will skew the debug listing line numbers. When using PDSOE, you can use ALT+L to go to the debug listing line number. Our build pipeline also stores the debug listings (produced by PCT) of our release builds in case version x.y.z threw some error.

You are looking for (although you really should not) RUN statement arguments. You simply add the arguments after the run. The curly braces you were using will try to include something. /* parent.p */ run daughter.p 'Teststring' 123. They are number only, by the looks of things. /*...

Also multiple variables of the same type on one line and more concise extents, my two lines above would need to be the following pre-var: define variable hwwin as handle no-undo. define variable hwfrm as handle no-undo. define variable hwbr as handle no-undo. define variable ht as handle...

And more importantly it means I can leave out no-undo clutter without getting scolded :-)