Wikipedia:Reference desk/Archives/Computing/2013 May 13

= May 13 =

E top-up and e-vouchers in the UK
How are E top-up cards and e-vouchers used in the United Kingdom for topping up mobile phone SIM card accounts?

I was not sure whether to ask this here or at the humanities reference desk (as it concerns finance), please move as necessary.

While looking for a Pay as You Go SIM card for use both in the UK and while roaming, I noticed the methods of topping up were quite limited (I am used to European SIM cards where I can top up at any TABAC or online with any credit card). Also, I had hoped that wikipedia would have had an article on the term E Top -up which is quite new to me. The related term e-voucher is also a redlink - the section in ORCA card appears specific to Washington State, USA.

Some websites partly explain the concept:, and ; but I was looking for how an E Top-up card is obtained and used by the end-user, and more background on the term and possible synonyms (for example "TopUp swipe card" from Vodafone sites). Ideally I would like to see a video of someone obtaining and using such a card with an ordnary non-smart mobile phone, or online in a browser.
 * I don't know the specifics of the system in the UK, but AFAIK in most places where such systems are used, they basically involve the person paying money (cash or possibly debit or even credit cards depending on what the norm in the local country and other factors) to whatever store offers the topup/reload vouchers, the store then entering the amount and the machine (in some cases it may be tied to the cashier machine) then prints the voucher with a unique number. The person can then either call a generally free number on their phone, follow the prompts (e.g. push 1 to topup, push 1 if you are using a topup voucher, enter the number and then press the hash key) and when down the system will likely tell them if their topup was successful, how much the topup was and what their current balance is (You successfully topped up your account with 20 dollars/pounds/whatever. You new balance is 44.96 dollars/pounds/whatever.) Alternative they can sent the topup number to a special SMS number and they will receive a reply telling them something similar to the voice service. I'm not sure that many bother with using online services for such vouchers but if they are possible, they would like involve logging on to your account and then selecting the topup with voucher option and entering the number. I'm not sure if it's common that you can topup other numbers with such vouchers although it may be possible if the voucher topup works exactly the same as with credit card etc. I think in most countries, normally people will just send the number by SMS if they want to gift someone a topup with a voucher, or give it in person.
 * In some cases you may also be able to buy the vouchers from vending machines, but particularly if vending machines accept credit or debit cards or something else which requires a network connection they may just ask you to enter the mobile number and then they tell the service to topup your number so you don't receive anything other than perhaps a receipt and an SMS when the topup has succeeded. Similar to the way ATM topups usually work AFAIK (although commonly you may also be able to tie a number to your ATM).
 * I'm not sure whether evoucher systems need a network connection. I originally thought they did since they got the unique topup number from the provider but on further consideration I think I'm mistaken, likely the machines can generate the number themselves and use a unique seed so the provider knows who it's from. (There will be some complexity in balancing the accounts since the machine and retailer will count the moment the voucher is produced, the provider only knows when it's used.) If they do and the machine only accepts cash, then perhaps it will have traditional topup vouchers so no network connection is needed but otherwise evoucher is a lot simpler since they only need electricity and someone to collect the cash every so often rather then also reloading the cards. It could of course be that both are in play depending on the country and provider or the machine can generate the numbers but does need regular reconciliation with the provider to reduce confusion from purchased but unused vouchers.
 * The top-up swipe card you refer to in the UK appears to be different from a voucher, from the description on the Vodafone site it sounds like you have a swipe card linked to your account which the retailer swipes to send the topup directly to your account so there's no voucher involved. Such a system definitely requires a network connection.
 * BTW, I'm pretty sure the evoucher is just a slightly modified version of the older system probably common in most countries (including Europe) where prepaid services were common using cards (vouchers) generally of the 'scratch and win' type (to ensure the card hasn't already been used before purchase) which is probably still somewhat common in some countries.
 * The advantage of the electronic system is you remove the need to keep any stock on hand of cards and all the problems associated thereof of needing to store, restock and manage stock levels to ensure you don't have too many or too few or they are lost or stolen, you may also be able to offer more values although I think many systems still only allow a small range of values for evouchers (i.e. you can't topup $24.53 and probably not even 24), however the range could be larger. From the providers POV, they don't have to produce the reload cards using reasonably high security systems (i.e. costly). Also for big retailers, they may let them tie it in to their checkout system so there's no need for separate machines or receipts. It also likely makes some degree of tracking easier since someone (as per my earlier comments on the network connection, it could be the provider, more likely the retailer or the machine) may keep records of precisely when the topup was purchased and the provider may keep records of what number if was used to reload. (And if they do use a unique seed, the provider can then ask or tell interested parties the retailer who has that seed for their records.) Besides the obvious and perhaps controversial use when the police are trying to track a mobile phone or tie it to a person, it would likely be useful in the even of disputes.
 * The main disadvantage compared to traditional cards is the cost of the machines (including maintenance etc) to generate the vouchers which someone has to pay (if the retailer integrates it in to their system then there's the cost of the integration). The machines at a minimum will also need electricity and likely the occasional refill of thermal paper. The machine will also likely take up more room in an accessible location (depending on the number on hand, the stock of cards may take up more room overall but these can be mostly stored elsewhere). And while you could print the vouchers and take them around, this would require a greater degree if trust compared to unscratched cards. Presuming they don't need a network connection or regular reconciliation with the provider, I suspect that vouchers from machines also have shorted expiry dates then cards (which could potentially never expire) to reduce the confusion from purchased and unused vouchers (particularly in the case of theft or alleged theft of the machine). And of course under either scenario, you may have to pay for the voucher the moment you print it out whereas I'm not so sure with cards and either way the retailer could likely return them unscratched and effectively not pay.
 * Either way, such vouchers do add cost but the overall advantage is that there's no need for credit cards or ATM cards or online banking or debit authorisation which not everyone may have or trust (in developing countries or 15 years ago even less so) which are usually required for alternative systems. And debit authorisation without online banking or similar is a complexity people may not want to deal with.
 * Note that if a network connection is available, instead of vouchers they could use a system whereby you enter your phone number similar to the way you do with ATMs and possibly some vending machines, that adds time while the checkout operator is waiting (even more so if the machine asks for it twice to reduce the possibility of errors) and considering some people don't know their number off hand and people may also be reluctant to enter their numbers if the retailer can see it. (The system used by Vodafone in the UK with swipe cards eliminates both problems.) It may be in some countries (and this would also apply to vending machines) that the voucher is familiar enough that most people prefer it even if there's no reason they couldn't just use an enter your number system. One obvious advantage of the voucher system is you can keep the number and not use it but have it on hand if it's ever needed (probably stored in your phone, particularly if it was printed on thermal paper), e.g. as a way of controlling usage. It also allows a simple networking based method of almost instant topups and credit where if a friend or someone who trusts you sells such vouchers you can SMS them and they can send you a voucher in reply and you can settle the transaction later. (They could also use send the topup directly to your phone but that would require them to have a network connection and even if they have a smart phone I don't think all providers make their commercial topup sites free. While they have to have the vouchers stored in their phone, once that's done there's a fair chance it'll also be faster to just send you a voucher then enter your number in to a topup site.)
 * One interesting point is that in some countries where provider enforcement of exact pricing is limited, you can sometimes purchase such vouchers (whether the cards or the evouchers) for slightly less than the face/topup value from certain retailers or perhaps from forums or other places. Although the amount saved is small since they don't actually earn much per transaction. (This can also happen with topup your phone directly systems, particularly if they allow value transfer cheaply and there's significant advantages to big topups.)
 * Nil Einne (talk) 04:27, 13 May 2013 (UTC)

Pioneer DDJ Ergo?
What's the difference between DDJ Ergo-V & DDJ Ergo-K? Which is better? 220.233.20.37 (talk) 08:47, 13 May 2013 (UTC)


 * The Ergo-V is given a 4.5/5 here but a 3.5/5 here. The Ergo-K has an average rating of 4/5 (based on 19 ratings) here. As for which is better, you should read through those pages and make the decision for yourself; as you probably know exactly what you want to get out of it. --Yellow1996 (talk) 16:31, 13 May 2013 (UTC)

GIF images/IE9 Favorites
This time, I've got two questions: 1) Why do some GIFs load in your default Internet browser rather than the usual picture-viewing interface? Is there a way to change this? 2) Is it possible - in IE9 - to check and see when you added a certain webpage to your favorites? Thanks! --Yellow1996 (talk) 16:15, 13 May 2013 (UTC)


 * Files do not load themselves; a user interacts with a user interface, causing the operating system to either directly or indirectly launch a computer program that loads the file. You may find our article on file association helpful.  If you are using Windows, you may adjust settings using the default programs control-panel interface.  Nimur (talk) 17:27, 13 May 2013 (UTC)


 * I tried to right-click and open the GIF file in Windows Live Photo Gallery (what I usually use) but it says that "Photo Gallery can't open this photo or video. The file may be unsupported, damaged or corrupted." - I'm fine viewing them in IE, it was just a curiosity question; but thank you anyway! :) also, does anyone know if my second scenario is possible? --Yellow1996 (talk) 17:36, 13 May 2013 (UTC)


 * If you're using Windows 7, this may help you. -- 140.202.10.130 (talk) 20:28, 13 May 2013 (UTC)


 * I'm actually on Vista - sorry (I really need to start specifying this.) But thank you for finding that info for me anyway. Like I said before, it's no big deal; I can view them in IE no problem. :) --Yellow1996 (talk) 01:24, 14 May 2013 (UTC)


 * Could it be that the ones loading in the browser are animated GIFs, which the regular picture viewer doesn't support ? (They might not appear animated, if they just repeat the same frame or if your browser is set to not show animation automatically.) StuRat (talk) 19:33, 14 May 2013 (UTC)


 * Yes!!! They do appear animated, so that's definitely the answer to this mystery. Thanks, StuRat! :) --Yellow1996 (talk) 23:39, 14 May 2013 (UTC)


 * You're quite welcome. StuRat (talk) 00:32, 18 May 2013 (UTC)

pascal programming "menu" question
I was assigned to write a program that resembles a "menu" in that there are a set of rectangles that change color when using arrow keys. There are two problems with my program and I can't figure out why: 1. even though I used the "readkey" line twice (by writing "ch:= readkey; if ord(ch)=0 {or keypressed} then ch:= readkey" I still have to press arrow keys twice to make it work. 2. When going from the first item of the "menu" to the last one by pressing the "↑" key, the first item remains colored although there's a "cleardevice" command at the beginning of the loop.

--Irrational number (talk) 21:58, 13 May 2013 (UTC)


 * I've added source-code formatting to your code for improved readability. Nimur (talk) 22:05, 13 May 2013 (UTC)


 * For #1 - it looks right to me (It has been long time since I've done this).  For function keys and arrow keys, etc, ReadKey first returns a 0, then the next call returns a code to indicate the key: 72 for up arrow, 75 for left arrow,  77 for right arrow, and 80 for down arrow.  (The 27 is for esc.)  So it looks basically right to me, based on my memory.  Trace through the program to see what is happening.  Bubba73 You talkin' to me? 23:03, 13 May 2013 (UTC)


 * PS - I would keep track of a line number, have a routine to translate the line number into the coordinates, and have the arrow keys change the line number and then update the screen coordinates. Bubba73 You talkin' to me? 23:07, 13 May 2013 (UTC)
 * And you don't need the begin/end inside the repeat/until. Bubba73 You talkin' to me? 01:40, 14 May 2013 (UTC)

I have a couple of other thoughts. (1) is ch an 8-bit character or could it be a 16-bit unicode character? If it is 16-bit, that could be the problem. (2) I'd test reading the arrow: Bubba73 You talkin' to me? 04:06, 14 May 2013 (UTC)
 * I did test it that way and it works right. But I still can't figure out what's wrong with the program. Maybe there's something wrong with my version of Pascal. There are other problems too. like when I floodfill the rectangle it fills it with white color even though I never used white in this program. Can anyone run the program in pascal, see if it works?--Irrational number (talk) 10:19, 14 May 2013 (UTC)


 * You haven't posted the whole program, told us which version of Pascal (it's not very standardised), or what OS. I'd personally recommend you post code at pastebin. -- Finlay McWalterჷTalk 10:24, 14 May 2013 (UTC)


 * There isn't really much else, just the variables and "gd:=detect" to use graph.--Irrational number (talk) 11:22, 14 May 2013 (UTC)


 * For what it's worth, here is part of some ancient code I managed to find in my archives. It might not make any sense but hopefully it will show you how we handled keys back in the DOS days. Why not just use Delphi now? Sandman30s (talk) 14:46, 14 May 2013 (UTC)

repeat key := readkey; until (upcase(key) in [#0, #8, #13, #27, 'A'..'Z', '*']); if key = #27 then begin nm := ''; exit; end; if ord(key)=0 then begin key := readkey; case ord(key) of   75 : begin                                 {left} pos := pos-1; if pos=0 then pos := length(nm); if nm='' then pos := 1; end; 77 : begin                                {right} pos := pos+1; if (pos=41) or (pos=length(nm)+2) then pos := 1; if nm='' then pos := 1; end; 83 : begin                                  {del} pos := 1; nm := ''; writeout; end; end; end; if (ord(key)=71) or (ord(key)=73) then      {Hm, PgUp} pos := 1; if (ord(key)=79) or (ord(key)=81) then      {End, PgDn} pos := length(nm);