OK so like a lot of us novice codehacks, I've gotten to the point where, through trial and error, I can throw together a relatively fun and reasonably stable game without really understanding WHY a lot of my code works, and I have a poor understanding of pointers and data management. I've tried studying, but since I lack a formal academic background in computer science and have 15 years of experience coding, the introductory stuff is way too easy, and the advanced stuff uses a ton of terminology I don't understand paired with code that I do.
I'm trying to understand why it is that sometimes I can define a new variable, point it at another variable, and then change the pointed data indirectly, and sometimes I can't. Here's an example where it DOES work as I expect:
NSString *myString = [MySingleton sharedMySingleton].singletonString;
myString = #"Hello there!";
[myString retain];
By changing the locally defined "myString" i can cause changes to the singleton string.
Here's an example where it DOESN'T work as I expect:
HUDLayer *windowBox = shopWindowBox;
[windowBox addChild: shop];
[windowBox retain];
In this case, HUDLayer is just an essentially blank file, and "shop" is a menu containing my store, and "shopWindowBox" is an instance of HUDLayer. If I call the code with [shopWindowBox addChild: shop], it works, but as soon as I try to define a new HUDLayer and point it, it doesn't work.
I understand that I'm doing a very fundamentally different operation, in one case I'm changing the contents of a string, and in another case I'm adding a child. The conclusion I've come to is "you can't add children to a pointed data", but am I really understanding this correctly, an if so why not?
I found a code error in a different block that was setting its visibility to FALSE.
I was attempting to make the code more plug-and-play by changing "shopWindowBox", "unitWindowBox", and "unlockablesWindowBox" all to be locally defined variable with windowBox, but my "hideUnitWindowBox" and "hideUnlockablesWindowBox" functions were setting the visibility of my shop window to FALSE after populating it.
I guess pointers not only work as I expected, they work BETTER than I expected... I stupidly merged 4 different windows into a single window using pointers.
Related
I'm working with appBuilder and procedure editor in Progress Release 11.6.
As mentioned in some previous questions, regularly I'm having problems with the appBuilder, not wanting to open files, corrupting them (deleting parts of source code), ..., one of the reasons now seems to be the limit that a procedure cannot exceed 32K, comments included.
At first I thought "Are we back in the stone age?", pardon my reaction.
But now I start thinking that we are completely abusing the whole concept, therefore I'd like to show my view on W-, P- and I-files, please confirm (or correct):
W-files are meant only to contain GUI definitions, like a form with some frames, buttons, fill-in fields, ..., any real programming needs to be done in P-files.
P-files contain the real intelligence: there the procedures and functions are elaborated, that can be used by the rest of the P-files, or finally by the W-files.
I-files are just there to include general behaviour.
Let me give you an example:
W-file:
DEFINE VARIABLE combo_information VIEW-AS COMBOBOX /* with some information on the content, if this is static */
...
ON CHOOSE OF combo_information DO:
RUN very_large_procedure.
END.
...
{about.i} /* see here-after */
...
P-file:
PROCEDURE very_large_procedure:
DO /* a lot */
END.
I-file (about.i):
/* Describes the help-about menu item */
While working like this (only putting the GUI-related things in the W-file and let the "real" programming be done in the P-files), the mentioned 32K limit will never be reached. In top of that, adding a procedure can be done easily, the appBuilder will not delete it as the appBuilder won't ever open the P-file.
Is my view correct (and what about the I-files)?
In case yes: one technical question: how can I launch a procedure from a P-file inside a W-file? (Obviously, the mentioned example can't work as in the W-file I did not mention where to look for the very_large_procedure)
The naming is arbitrary and you may occasionally find other extensions being used. Having said that:
"W" is for "window", it is supposed to contain code that is related to making a GUI work. It is very often abused to contain any sort of code. It is usually abused in that way by people who learned to code on the app builder or who have never coded on anything but Windows.
"P" is for "Progress" and retconned to "Procedure". It was the standard back in the old days prior to the appearance of Windows GUI code. Any "headless" code or character mode code would typically go into a dot-p file.
"I" is for "include". This is a very old school way to create reusable code snippets and common "header files". Include files are commonly parameterized. Potentially with either named or positional arguments.
Another major extension is ".cls" files. These are for OO4GL classes (OpenEdge 10 and above).
Launching procedures is acheived by running them:
RUN myproc.p.
or
RUN guiproc.w.
Or, if by "launch", you mean "start a session" then you use the "-p procedureName" startup parameter along with prowin32.exe or prowin.exe for Windows GUI code or _progres.exe for batch or character code.
EDIT:
I went back and provided a long explanation of each of the below.... Then I started thinking. I think my issue was the division element (getUnitDivisionFactor()) was not observable. I changed this to an observable data type and it all started working. So rather than delete this "stupid question" I will leave it around. Perhaps this will help someone else.
I am using JFXtras 2. There is an "LCD" widget that has a valueProperty binding. It is a double binding. I am binding like this... Which is not working...
xLcd.valueProperty().bind(TinygDriver.getInstance().m.getAxisByName("x").getMachinePositionSimple().subtract(TinygDriver.getInstance().m.getAxisByName("x").getOffset()).divide(tg.m.getUnitDivisionFactor()));
The problem I really need to do the subtraction first..
(getMachinePositionSimple - getOffset()) / getUnitDivisionFactor()
However I am a bit stumped on how to do this in a single binding setup. I think number bindings might be the way to go. However, not quite sure how to set that up right?
Any help would be great.
Riley
The getUnitDivisonFactor() was returning a regular double data type. I changed this to a SimpleDoubleProperty and everything just started working.. See
xLcd.valueProperty().bind(TinygDriver.getInstance().m.getAxisByName("x").getMachinePositionSimple().subtract(tg.m.getAxisByName("x").getOffset()).divide(tg.m.gcodeUnitDivision));
Our application is made in good (?) ol' classic ASP. Not ideal but it works and it's pretty stable - has been for 10-15 years. It is not particularly well documented in places, such as where a 'translation' (client-controlled piece of text) appears. All we have against a translation is a clientid and translationid, neither of which are particularly helpful. I've tried searching the (10s of thousands of lines of) core code for gettrans(1) (translation 1) and can see that doing this for another 3100 is going to be a nightmare, not to mention inaccurate as there are many functions which are called with a transid passed into them, and then they call gettrans(transid).
My last thought on this matter is the possibility that we could maybe detect, from gettrans, where a function is called from - not just the line number but the file name of the include (thankfully the includes are named usefully so figuring out where a translation is used should not be too hard!). I highly doubt that it would be possible to get the include name on the basis that includes are processed before ASP, but I'll settle for the overall filename and then we can combine the includes to get to the line of code and log the include file name.
I very much doubt this is possible and can't find anything on SO or Google. Does anyone know of any way to achieve this, or have any pointers on what I might try? Thanks in advance.
Regards,
Richard
Most you can achieve is getting the currently executing script, which can be obtained by:
Dim currentPage
currentPage = Request.ServerVariables("SCRIPT_NAME")
When inside included page it will give you the "parent" page.
However getting "callee" information is not possible with classic ASP as far as I know, so you will have to add another parameter to the function being called then change all calls to pass the parameter in order to identify where it comes from. Looks like someone did something similar and called it ASP Profiler, use it at your own risk of course. (Never tried myself)
Because I rush in development (a lot of whip cracking here) and declare my objects at the top of the function and instantiate inside my try-catch block, I get a lot of the good old "object not set to an instance of an object" errors while doing TDD, and later if I do miss a branch that object was used in (doing VB now, would prefer C#) or just in every day coding, object not set to an instance of an object is a bit vague. Sure the stack trace sends me to the line the error occured at, but it would be nice if I could modify my logging to either name the object or its type because sometimes I have multiple objects on the same line. It's not the end of the world, but in the end it would save me a few minutes each day. Any ideas on how I can pass the info on which object wasn't set? Thanks
It is non trivial to "modify your logging" to output variable name or type - I am sure that if the framework could easily get this information from the executing IL, MS would have included it the null reference exception.
Prevention is always better than cure. Here are a couple of tips I would do
Fix your compiler warnings
C# would generate a compile error if it detects that there are code paths that could use an unassigned local variable. [For some odd reason] VB.Net will still compile but the compiler will generate a warning - take heed of these and go and fix the code and you should never run into the problem of unassigned variables again!
Adopt a different coding pattern for variable declaration
I appreciate that method variable scope in ye olde VB was that the variable was visible throughout the entire method regardless of where it was defined. As a result, it was a reasonable practice to put all your var declarations at the top of the method. VB.Net of course is different - you can only use variables after they are declared and so it is OK (and I would say preferable*) to put the declaration (and assignment) closer to where the variable is actually used. This should help you see "by eye" if your program logic means it is possible to use an unassigned variable.
Some people think this is a think that it is always good practice to put variable declarations in a block at the top of the method. I will not argue against them but I would say that that approach works best with small methods that do not use lots of variables.
Over the past three weeks, I have lost at least 120 man hours because of some lesser known functionality in ActionScript 3. One of the problems was that, with Internet Explorer, if there are too many messages sent through LocalConnections, it will slow the messages sent through, but in the standalone player and in Firefox, this threshold is significantly higher. Another was that the static values of a class are instantiated even if the member itself is not being used:
import path.to.FooClass;
private function thisIsNeverCalledButItEnsuresThatFooClassIsImported():void
{
var f:FooClass = new FooClass();
}
Since FooClass had a static reference to a Singleton, that Singleton was instantiated so when I loaded a Module which used that Singleton, it would bind to values in an unpredictable way.
Additional cases where things behave in an unexpected way:
MovieClip.addFrameScript
flash.trace.Trace as a class
int is a faster incrementer class, Number is faster for mathematics, and uint is incredibly slow.
PrintDataGrid, if it has only one page, needs to have an empty value appended to the end of its dataProvider
If you use try...catch around two LocalConnections and connect them to the same channel, you will force garbage collection without needing System.gc
So here's the question (and I'm sorry for omitting this in the original post), is there any consolidated documentation for this type of behavior anywhere? Is there any (even non-Adobe) documentation on these issues (websites, forums, books, ANYTHING)? I know that these things are definitely easy enough TO document, but has anyone done so?
If not, am I missing anything? Are there other issues which I should know about?
This kind of useful information is very often not "centralized". Moreover, what you are looking for is something related to the experience of the programmer (more than to official docs).
FYI, there are two other methods for ensuring a class is included.
#1 - This syntax is actually used in the Flex source code:
import path.to.FooClass; FooClass; // note double reference
public class References
{
// No references needed in this class
}
#2 - Use the includes command line argument
-includes path.to.FooClass
You can always submit your experience using the "feedback" section in the help. Unfortunately, this is less obvious than the link that used to be at the bottom of each page in the older help files (which also served the useful function of opening a browser window with the web version of that help page).
Adobe says that it incorporates the comments from previous versions of the help into new versions, but my own observation suggests that there are instances where it does not happen. However, that and the appropriate cookbook are still the best avenue for those who believe that this kind of information should be centralized.
Note that the whole purpose behind modules is to avoid compiling code multiple times, so importing FooClass kind of defeated the purpose. The problems you had in this instance are just one of the many that happen if you use Singletons, and it's unfortunate that the first official Framework, Cairngorm, encouraged their widespread use. Check out http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/ .