I really got to say, finally getting friends saying it is a cool phone shows people's acceptance and awareness. I really glad Nokia makes such nice iconic phone and be an exclusive phone maker for WP platform. It really helped WP ecosystem a lot and I am grateful to it.

I am grateful for HTC and Samsung early supports, but, Nokia really turned the ecosystem around.

Still a long way to go though.

What I have noticed is the Apple fanbois take an interest when they see I have a 920.  They usually ask to look at it and then make a big show of criticising it's weight, to which I reply 'Yes, it is a real man's phone all right'.

How we all laugh.

5 hours ago, cheong wrote

Btw, after using my Lumia 920 for a month, I'll say it still "needs more polishing", mostly in IE (no forward button and no Flash support, although I understand the Flash thing is not Microsoft's fault) and Office part (Lots of gliches here and there... For example, it's lame to make spreadsheet readonly simply because the worksheet is protected or contain VBA... these 2 combined makes it almost no value to put any effort to make it included in coperate workflow. I've had assumed things would integrate more smoothly within Microsoft, and Workflow integration could have been a strong point to push company's executives to move to WinPhones).

So anything containing VBA doesn't work in WP or the online version of Office? Anyone has more details? WOW. Isn't this bigger then Silverlight biting the dust?

The problem I'm facing is that, in WP version of Office 2013, if the workbook contains VBA, all cells there will be automatically treated as read-only.

The is known limitation in their FAQ section.

Jan 28, 2013 at 5:55 PM, fanbaby wrote

*snip*

So anything containing VBA doesn't work in WP or the online version of Office? Anyone has more details? WOW. Isn't this bigger then Silverlight biting the dust?

8 hours ago, PaoloM wrote

Are you really going to let your life be dictated by fact checkers?

14.7% of people do. I read it on Wikipedia.

1 hour ago, Harlequin wrote

I was hoping to get a 920, but the phone contracts up here in Canada are almost criminal.

I could not talk myself into an AT&T contract to get a 920... People tend to think the hardware is a "fail" for lower than expected sales while the carriers are pricing high end smartphones (contracts) out of a lot of folks budgets.

11 hours ago, evildictait​or wrote

*snip*

Office Pro Plus in Office 365 is the same Office bits as Office 2010, so any VBA development you've done that works with Office 2010 today will continue to work in Office 365.

I believe he was talking about the Windows Phone and Web editions and not the desktop products. WP & Web don't support macros.

3 hours ago, Harlequin wrote

I was hoping to get a 920, but the phone contracts up here in Canada are almost criminal.

2 hours ago, magicalclick wrote

@DeathByVisualStudio: yeah, I am not sure how Office 365 has anything to do with WP. But imo, WP naturally cannot do fso and domain db, thus, doing VBA on those is impossible. I am not sure if this is why they don't support VBA to avoid confusion in what can be done using VBA.

I've built data collection spreadsheets in the past that contain macros but the macros were only used on the desktop after the data was collected. Fortunately the collectors were using laptops so there was no issue. Ideally some would have preferred a mobile device like a phone. In that case the spreadsheet would be read-only on the phone even though all the user needs to do is enter data. I hope they allow this someday for quick & dirty mobile data collection without having to split-up the spreadsheet into two workbooks. I'm curious how the Office mobile competitor apps handle this? If I have some time I'll run some tests.

Aside from that, there are insane technical problems in porting a very specific execution environment and object model to run in a browser and/or on a mobile device.

If data collection is that important, then you need to use an app. Macros are probably the worst possible solution.

The only way I can see it working is insisting that users of the web-browser based Office app install an ActiveX component to run those VBA macros, but that sounds like it would be ( a) painful, (b) undermine a lot of the point of having an online product, (c) give Microsoft critics something different to complain about and (d) probably introduce all sorts of extra complexity, security problems and so on, all just so that VBA macros work in the web when you could instead just use Office 2013, connect to 365 and get the VBA macros through that instead.

2 minutes ago, kettch wrote

@DeathByVisualStudio: Macros in a browser are a bad idea. Do you really want Word macro virii running amok in your browser? Do you want poorly written macros sucking battery and performance from your mobile device?

Aside from that, there are insane technical problems in porting a very specific execution environment and object model to run in a browser and/or on a mobile device.

If data collection is that important, then you need to use an app. Macros are probably the worst possible solution.

I'm not sure where all of this came from since I said:

but the macros were only used on the desktop after the data was collected.

Sounds to me you're just trying to make me out as a crazy troll. Nice try.

IMO, WP and the web versions should allow the spreadsheet containing macros to be edited but the macros are dormant. 

3 minutes ago, magicalclick wrote

@DeathByVisualStudio: I would setup a simple Skydrive enabled data entry spreadsheet. And have VBA spreadsheet on PC to grab the data from SkyDrive folder.

While that would be a nice solution it was more than what I had time for.

2 minutes ago, DeathBy​VisualStudio wrote

Sounds to me you're just trying to make me out as a crazy troll. Nice try.

I was just saying that VBA macros in the browser are hard to implement and would have lots of problems.

You need to stop taking everything people say so personally.

Also; for the record, I'm pretty sure I've never actually called you a troll, although you've accused me of doing so several times now.

Anyway, I don't want another thread to get derailed. Let's get back on topic.

49 minutes ago, evildictait​or wrote

*snip*

I was just saying that VBA macros in the browser are hard to implement and would have lots of problems.

You need to stop taking everything people say so personally.

Also; for the record, I'm pretty sure I've never actually called you a troll, although you've accused me of doing so several times now.

Anyway, I don't want another thread to get derailed. Let's get back on topic.

I'm not taking things personally. I'm just pointing out the ongoing "misunderstandings" that folks like kettch and yourself make in order to diminish the possibility that there is an issue in the first place. You can claim troll badging innocence all you want but it's pretty obvious you're willing to infer it. That's the same tact Fox News uses with their "Some People Say" technique. Honestly I could care less if you take a thread negative by skewing context but you certainly have to be willing to take what you give. So on to today's lesson...

It was pretty clear that cheong wasn't talking about the desktop version of office nor some difference between them:

15 hours ago, cheong wrote

Missed this thread...

The problem I'm facing is that, in WP version of Office 2013, if the workbook contains VBA, all cells there will be automatically treated as read-only.

The is known limitation in their FAQ section.

Yet you responded as if he had:

15 hours ago, evildictait​or wrote

*snip*

Office Pro Plus in Office 365 is the same Office bits as Office 2010, so any VBA development you've done that works with Office 2010 today will continue to work in Office 365.

I corrected you in order to keep the issue on-topic:

3 hours ago, DeathBy​VisualStudio wrote

*snip*

I believe he was talking about the Windows Phone and Web editions and not the desktop products. WP & Web don't support macros.

And instead of a post stating "oh yeah, my bad" you and kettch move on to my latter post:

1 hour ago, DeathBy​VisualStudio wrote

*snip*

I've built data collection spreadsheets in the past that contain macros but the macros were only used on the desktop after the data was collected. Fortunately the collectors were using laptops so there was no issue. Ideally some would have preferred a mobile device like a phone. In that case the spreadsheet would be read-only on the phone even though all the user needs to do is enter data. I hope they allow this someday for quick & dirty mobile data collection without having to split-up the spreadsheet into two workbooks. I'm curious how the Office mobile competitor apps handle this? If I have some time I'll run some tests.

And "misunderstood" it as if I meant for the macros to be executable on the web and/or WP:

1 hour ago, kettch wrote

@DeathByVisualStudio: Macros in a browser are a bad idea. Do you really want Word macro virii running amok in your browser? Do you want poorly written macros sucking battery and performance from your mobile device?

Aside from that, there are insane technical problems in porting a very specific execution environment and object model to run in a browser and/or on a mobile device.

If data collection is that important, then you need to use an app. Macros are probably the worst possible solution.

58 minutes ago, evildictait​or wrote

@DeathByVisualStudio: How would you expect web-browser-based Office apps to cope with VBA macros that do things like interact with the FileSystemObject, or do WScript.Shell.Exec("malware.exe") ?

The only way I can see it working is insisting that users of the web-browser based Office app install an ActiveX component to run those VBA macros, but that sounds like it would be ( a) painful, (b) undermine a lot of the point of having an online product, (c) give Microsoft critics something different to complain about and (d) probably introduce all sorts of extra complexity, security problems and so on, all just so that VBA macros work in the web when you could instead just use Office 2013, connect to 365 and get the VBA macros through that instead.

So there may be no more "misunderstandings" let me be clear:

1. Macros, VBA, and the like only run the desktop.
2. Macros, VBA, and the like are suspended on the WP and web versions but allow for data entry.
3. Typically the macros I write are tied to shortcut keys and run on demand on the desktop version.
4. I could care less if the WP and web version support macros

Therefore in my case the issues you and kettch have brought up are out of scope and moot.

1 hour ago, DeathBy​VisualStudio wrote

*snip*

Honestly I could care less if ...

I know the 920 has a better camera, screen and more memory, but can you add memory to these?

4 minutes ago, Dirtbagg wrote

but can you add memory to these?

Nope. Personally, I wouldn't know what to do with the memory it has, but if you need more, you're out of luck.

4 hours ago, evildictait​or wrote

@DeathByVisualStudio: How would you expect web-browser-based Office apps to cope with VBA macros that do things like interact with the FileSystemObject, or do WScript.Shell.Exec("malware.exe") ?

The only way I can see it working is insisting that users of the web-browser based Office app install an ActiveX component to run those VBA macros, but that sounds like it would be ( a) painful, (b) undermine a lot of the point of having an online product, (c) give Microsoft critics something different to complain about and (d) probably introduce all sorts of extra complexity, security problems and so on, all just so that VBA macros work in the web when you could instead just use Office 2013, connect to 365 and get the VBA macros through that instead.

That point is weak. In desktop version of Office you can always edit the spreadsheet with macros disabled (by not enabling it from the security bar). Why wouldn't WP version of office just assume macros are always disabled and allow us to edit the data?

You should get a Windows Phone 8 and test it out yourself instead of under the impression. Because the topic is talking about Windows Phone 8's Read Only limitation on macro enabled workbook. Or at least actually go read the official FAQ from the poster who raised his concern.

• You might not be able to edit a Microsoft Office document on your phone depending on what's in it or how it was last saved. Here are some of the more common things that make a document read-only on your phone.

  The file is:

  • Saved as an older type of Microsoft Office document, such as a Microsoft Word 97-2003 document (.doc), Microsoft Excel 97-2003 workbook (.xls), or Microsoft PowerPoint 97-2003 presentation (.ppt).
  • Digitally signed.
  • Marked as final.
  • Protected using rights management.
  • Protected with a password.
  • Protected with restricted editing rights.

  Microsoft Word documents are read-only if they have:

  • Track Changes enabled.
  • Frames.
  • Custom markup (custom XML, Structured Document Tags (SDT), or smart tags).
  • XML tags with unsupported values.

  Microsoft Excel workbooks are read-only if they have:

  • Functions that aren't supported on the phone. For info about which Excel functions are supported, see the Microsoft Support article about supported content in Excel Mobile.
  • Scenarios.
  • Data validation in one or more cells.
  • Array formulas.
  • Data tables.
  • Slicers.
  • Macros enabled.
  • Large column or row widths.
  • Formulas that contain links or references to other workbooks.
  • Formulas with structured references.
  • Formulas that contain references, content, or formatting beyond cell IV16384.
  • Formulas that are longer than 512 characters or have more than 30 arguments in them.
  • Tracked changes.
  • Dialog sheets.
  • XML markup that isn't formed correctly.
  • OLE objects or ActiveX controls.

  For Microsoft OneNote notebooks, you can't edit:

  • A page from a notebook that was sent as an email attachment.
  • A notebook that is shared on SkyDrive, a Microsoft SharePoint site, or a SharePoint Online site, and marked as read-only.
  • A notebook that has a corrupted page.

  For Microsoft PowerPoint presentations, you can only make certain types of edits on your phone. Some examples include editing text in a text box, adding or editing notes, changing the order of slides, or hiding slides. For more info about editing a PowerPoint presentation on your phone, see Use PowerPoint Mobile.

   

-Josh

35 minutes ago, JoshRoss wrote

now kiss and make sweet business love over my already stretched thin data-plan.

Get your boss to pay for your dataplan 

But wait, we might as well just export the file as PDF and view it on a Windows Phone. In that case I could have uninstalled Office for WP and save a few GB of storage. Just install PDF viewer for WP which is 4MB in size would be enough.

Is that what you want to tell us?

I don't know what's involved in Office dealing with macros, but yes, the document should be editable in as many cases as possible. When a macro is detected, you would need to firmly warn the user that any behavior that relies on macros will be broken.

There can be no VBA on the web or on mobile devices. It's too old and crusty, and the tools aren't any good. There would need to be some kind of superset to WinRT that Office documents could have access to, replacing VBA. The execution could be split into two parts. The "front end" could handle formulas and general editing. If you were running on a desktop, then the executable package could run locally, or could run on a server, much like Excel Services works today. On the web, this would continue to be the default execution method.

I'm not certain how something like this would work on a mobile device. Maybe it would be a balance of the two, depending on what would be running.

1. What will replace it? DOTNET or JavaScript?
2. How important is scripting to office?
3. Where the heck is a website which is analogous to Access?

Sorry my comment raised so much commotion 

My problem with macros in Office/Corel has always been the same: Nobody ever knows when to stop.

One of my projects is to help in figuring out how to replace hundreds of WordPerfect macros that do nothing more than pop dialogs to walk people through filling out a form. Their initial solution was to port them to Word, and then write a Word add-in that parsed the document template for fields and did throw the same dialogs. That's a solution for <10 forms. More than that and you really should buy a forms product.

Think about how many people go to an Excel or Access class, and the next thing you know they are running their business off of a flakey half baked amateur-hour ERP system. Maybe that works in some cases. It gets worse in an enterprise where there are all kinds of automation going on that should really be done somewhere else. However, it's all IT's fault when it breaks.

As far as Access goes, there already is a website that does what Access does. You can upload an Access database to Office 365 and have it run as a web application. I know that's not quite what you meant, but I've never heard of a web application that let people build horridly crude and ugly abominations that are banned by the Geneva Conventions. I can't tell you how frustrating it is to have vendors in certain vertical markets (medicine, law enforcement) who have made a fortune selling Access databases. Yeah, just because a retired doctor or cop can extrude an Access application with a better understanding of their business, doesn't make it ok for them to actually sell it.

Office 2013 supports a HTML5/JavaScript based add-in model, and that's probably the way to go forward. Especially since it probably gives them the ability to enable these apps and automations to un in the browser in the future.

12 hours ago, cheong wrote

@JoshRoss: With this reasoning you may tell Microsoft to not bother making Excel for WP, ExcelViewer for WP would have been good enough.

Yep.  If you honestly believe you are going to create anything of value in excel on a phone, you are arguing an extreme edge case.  You should count your lucky stars that you can painfully update generic xlsx files that don't have the above listed limitations.

But wait, we might as well just export the file as PDF and view it on a Windows Phone. In that case I could have uninstalled Office for WP and save a few GB of storage. Just install PDF viewer for WP which is 4MB in size would be enough.

That's just more silly extremism, but if you'd rather lose any excel functionality at all simply because you can't manipulate fields that contain macros, be my guest.

It's a security hole, it's prohibitively difficult to implement, and it's an edge case that only serves to perpetuate poor application design choices.  If you are writing LOB applications in excel, you are a hack.

43 minutes ago, ScanIAm wrote

*snip*

If you are writing LOB applications in excel, you are a hack.

This is so true. We have engineers who have built complex apps in Excel. They were very "modular" in their design where each workbook in the app was one of several "modules" that made up the application. Talk about a dependency clusterf___.

That said if I throw together a quick & dirty data collection spreadsheet that has simple cleanup macros attached my collectors shouldn't be blocked from entering data against that spreadsheet when using it on a WP or from the web. When macros are disabled they pose no security risk.

I fear that this is another case of somebody declaring that "change x is soooo simple" without having any knowledge of the work needed to plan, engineer the change, make the change, not introduce bugs, test, test, test, make work across all languages and configurations, test, test, test...

Without having any special knowledge, my guess is that it's simply a matter of prioritizing work for each release.

1 hour ago, Kental2 wrote

So weird, I've been working in the private sector for 10 years now and I've never come across a single office macro at any of the companies I've worked for. 

You've obviously never worked in the American Financial system.

58 minutes ago, kettch wrote

@DeathByVisualStudio: You're assuming that you know why macro-enabled spreadsheets are read-only.

I fear that this is another case of somebody declaring that "change x is soooo simple" without having any knowledge of the work needed to plan, engineer the change, make the change, not introduce bugs, test, test, test, make work across all languages and configurations, test, test, test...

Without having any special knowledge, my guess is that it's simply a matter of prioritizing work for each release.

I never said I knew why they were read-only and I never said the solution was simple. I'm saying it's a problem. And rather than simply acknowledging the problem exists you go out of your way to give Microsoft every out on why they haven't/shouldn't fix this. If anything its an opportunity for Microsoft to do better. It's too bad you don't seem to see it that way.

Your problem exists, but what I'm saying is that it's not the problem that Microsoft should be solving.

25 minutes ago, DeathBy​VisualStudio wrote

*snip*

I never said I knew why they were read-only and I never said the solution was simple. I'm saying it's a problem. And rather than simply acknowledging the problem exists you go out of your way to give Microsoft every out on why they haven't/shouldn't fix this. If anything its an opportunity for Microsoft to do better. It's too bad you don't seem to see it that way.

Microsoft has finite resources. Every feature they add comes at the expense of another feature they can't add.

The question isn't "Should Microsoft have implemented VBA on Windows Phone", but rather "What feature should they have not implemented in order to spend time coding, testing and security checking VBA on Windows Phone",

Or if you prefer to use the future tense "Should Microsoft introduce VBA into the next version for the small-ish numbers of people that want it, or should they add something else, like support for older versions of Excel documents?".

Like you say, I could demand the ability to open WordPerfect, Quattro, Lotus Notes, and reverse binary encoded paradox indices, but that's not the right way of going about it. I don't think that the WP team should spend time supporting every file format under the sun. Instead, this sounds like something that Hotmail/SkyDrive needs to handle. Give me a message that says, "We can't open this document locally, would you like to download a converted version?" Instead of spending the time on supporting stuff that nobody on the phone cares about, you can use some of the conversion expertise that they already have, leverage the cloud, and still provide some advanced features without compromising the security or performance of the device. You also get the ability to support the desktop, iOS, Android, etc with a single backend service. You go from spending a lot of time on a useless feature that a ridiculously small number of people will care about, to something that's much more useful.

Of course, this is all wishful thinking too.

35 minutes ago, evildictait​or wrote

*snip*

Microsoft has finite resources. Every feature they add comes at the expense of another feature they can't add.

The question isn't "Should Microsoft have implemented VBA on Windows Phone", but rather "What feature should they have not implemented in order to spend time coding, testing and security checking VBA on Windows Phone",

Or if you prefer to use the future tense "Should Microsoft introduce VBA into the next version for the small-ish numbers of people that want it, or should they add something else, like support for older versions of Excel documents?".

That's funny because, again, I'm not talking about wanting support for VBA on the phone. I'm talking about blocking VBA but allowing the spreadsheet to be edited. You are oversimplifying why Microsoft shouldn't work on this feature by making it out to be a much broader scope that the issue presented.

10 minutes ago, DeathBy​VisualStudio wrote

@evildictaitor:

That's funny because, again, I'm not talking about wanting support for VBA on the phone. I'm talking about blocking VBA but allowing the spreadsheet to be edited. You are oversimplifying why Microsoft shouldn't work on this feature by making it out to be a much broader scope that the issue presented.

Every feature has to be written and tested before it can be released. If VBA-enabled documents were disabled but the document editable, that means that WP needs to be able to save documents with VBA macros in, otherwise you end up with customers complaining that when they get sent a document, they fill it out and email it back, all of the macros are missing.

Disabling editing when there is stuff in the document you're not sure you can preserve over an edit is less work than enabling edits and potentially corrupting the file or throwing away information in the document that customers might really want.

44 minutes ago, evildictait​or wrote

*snip*

Every feature has to be written and tested before it can be released. If VBA-enabled documents were disabled but the document editable, that means that WP needs to be able to save documents with VBA macros in, otherwise you end up with customers complaining that when they get sent a document, they fill it out and email it back, all of the macros are missing.

Disabling editing when there is stuff in the document you're not sure you can preserve over an edit is less work than enabling edits and potentially corrupting the file or throwing away information in the document that customers might really want.

Which is not the same as: 

"What feature should they have not implemented in order to spend time coding, testing and security checking VBA on Windows Phone"

nor

"Should Microsoft introduce VBA into the next version for the small-ish numbers of people that want it, or should they add something else, like support for older versions of Excel documents?"

Do you really think preserving parts of a file that the app doesn't support is the same scope as adding VBA support?

Isn't the very nature of Office Open XML Format is to allow support for different versions of Office apps to with different feature sets to work on the same file without rendering it useless? It certainly isn't free to implement but it isn't near the scope of adding VBA support to the web and WP versions.

So EvilD have you settled on a scope yet or are all issues not raised by you nor kettch bad ideas because they require such things as development time and testing -- like any other feature?

1 hour ago, evildictait​or wrote

Every feature has to be written and tested before it can be released. If VBA-enabled documents were disabled but the document editable, that means that WP needs to be able to save documents with VBA macros in, otherwise you end up with customers complaining that when they get sent a document, they fill it out and email it back, all of the macros are missing.

That would be strange. The macros in .xlsx file is in seperate subfolder (XLSX format is zip file with folders of XML files). That means it's at least "at the surface" no implication to modify data and save the file again with macros leave there un-touched.

Disabling editing when there is stuff in the document you're not sure you can preserve over an edit is less work than enabling edits and potentially corrupting the file or throwing away information in the document that customers might really want.

In Office for Windows Desktop we can still edit data with macro disabled. Just display a line on top that macros will be always disabled on WP version would be enough. At least those want to edit can edit.

That's way better than turning your Office for WP to be ExcelViewer for all the documents that contains workflow related macros.

ExcelViewer for Windows Desktop sized 75MB. Even if you make it 5 times to cover other office document viewers, it's still much lighter than the current size of Office for WP.

32 minutes ago, DeathBy​VisualStudio wrote

Isn't the very nature of Office Open XML Format is to allow support for different versions of Office apps to with different feature sets to work on the same file without rendering it useless? It certainly isn't free to implement but it isn't near the scope of adding VBA support to the web and WP versions.

I don't know a whole lot about Office, but I was pretty sure the reason for the Office XML was to do with complying with European regulations.

So EvilD have you settled on a scope yet or are all issues not raised by you nor kettch bad ideas because they require such things as development time and testing -- like any other feature?

I'm not saying all features are bad. I'm just saying that at Microsoft they have the phrase "all features start at minus 100 points".

It means that since there's an opportunity cost to every feature, and an actual cost in terms of testing and implementing it, your feature can't merely be "better than now" to be implemented. Every line of code you add has to be maintained, localized, tested, potentially adds a security bug or a feature that you have to backwards support, so features have a high opportunity cost.

You seem to consistently mistake my attitude as being one of saying "MS don't need to add that feature" as some kind of "defending" Microsoft. It's actually quite the opposite. I'm saying that they should be implementing better features, because if you only get to pick say 6 new features over the next few months, I'd rather they be ones that people want, rather than ones like VBA on a WP that so far as I can tell, few if anybody actually need.

2 hours ago, evildictait​or wrote

*snip*

I don't know a whole lot about Office, but I was pretty sure the reason for the Office XML was to do with complying with European regulations.

While that may be part of what gave birth to OOXML it was really all about the money and control. Many of government agencies were yammering about making open standard document formats a requirement. Here's just a sample from Mary Jo. Microsoft got caught with it's pants down as ODF beat them to certification. Microsoft was worried that their beloved Office was going to be tossed aside in favor of Open Office by these government agencies. In response Microsoft had to fast track OOXML through the standards review which many would agree was ugly at best.

In any case the trigger that caused OOXML to be created doesn't detract from the fact that it's very nature makes it more suitable for supporting editing of documents by applications that can't support the full feature set -- all the while without corrupting the document. Like I said before I doesn't mean it's free to implement but it's a whole lot closer than you suggest.

*snip*

You seem to consistently mistake my attitude as being one of saying "MS don't need to add that feature" as some kind of "defending" Microsoft. It's actually quite the opposite. I'm saying that they should be implementing better features, because if you only get to pick say 6 new features over the next few months, I'd rather they be ones that people want, rather than ones like VBA on a WP that so far as I can tell, few if anybody actually need.

I hope you can see how easy it would be to make the "mistake" when you do so much of your defense here by taking things out of context or changing the scope. When you do that it makes you appear very desperate and at least in my book seem very disingenuine in your efforts. Even with great explanations like this:

I'm not saying all features are bad. I'm just saying that at Microsoft they have the phrase "all features start at minus 100 points".

I think you are unkind to Access. The fact that you can make abominations with it doesn't mean that you will. As a pre-internet tool I think it's one of the best. What is an abomination is the HTML output of access and all the other apps in office.

38 minutes ago, DeathBy​VisualStudio wrote

Like I said before I doesn't mean it's free to implement but it's a whole lot closer than you suggest.

Oh yay. Another free feature for Microsoft to implement, test, review, commit, merge, localize, security audit, and maintain for 10 years.

I hope you can see how easy it would be to make the "mistake" when you do so much of your defense here by taking things out of context or changing the scope. When you do that it makes you appear very desperate and at least in my book seem very disingenuine in your efforts. Even with great explanations like this:

Calling people who are trying to answer your questions "deperate" and "disingenuine" (sic), when they are trying to answer your question is against the ToS of C9.

I know I haven't necessarily been very diplomatic of late, but neither have you.

Let's move on.

There are tons of people who would want a less complicated workaround and just edit the file on their phone, save it on skydrive (or email back as attachment), and tell the assistant to run the macro on the other side of planet, and refresh the excel to get the updated data, all on a quick business meeting in some casual coffee shop. This workflow is a lot more agile when the person doesn't always carry a laptop with him. Doing any work around would make the workflow a lot less reliable when extra complexity is added to the process.

We can all sit around pretending to know why MS does this or keep trying to find excuses for MS. But, we forget the main point of this topic. The original poster faces a difficulty due to software limitation. He wants the system to improve and support his use case. And I am sure many people would want the same thing if they are aware of the potentials of such capability. The demand is there. The point is, should we support the use case and hope MS improves it? Or should we just let the limitation escalate until yet another competitor supporting the use case as MS is unwilling to address it? I have seen many instances that MS doesn't believe users deserve what they want and forced them to seek solution from competitors. MS can always play the "I am giant" game, but, that doesn't always workout.

5 minutes ago, magicalclick wrote

I sincerely believe the request on making VBA excel sheet editable is a very valid request and is often quite urgent for small to mid businesses. 

There are tons of people who would want...

And I am sure many people would want the same thing...

The demand is there

If loads of people want it and are asking for it via MS support tickets and via their Microsoft business liaisons  I'm sure it will be introduced in the near future.

Features don't implement themselves. I'm sure VBA macros in an editable document is on the list of things that those developers need and want to implement. I'm just not sure it's very high on that list.

If there's genuine business demand, a couple of CTOs phoning MS and say that they'd move to WP in their business fleet "if only documents with VBA macros were editable" might shift it up a few places in the list.

But my suspicion is that like a lot of features "demanded" on the interwebs, there's a fairly limited set of people that really want this feature, and a fairly large number of people that want the features higher up the list.

http://windowsphone.uservoice.com

12 hours ago, evildictait​or wrote

*snip*

Oh yay. Another free feature for Microsoft to implement, test, review, commit, merge, localize, security audit, and maintain for 10 years.

Oh yeah the same old dismissive excuses.

 

*snip*

Calling people who are trying to answer your questions "deperate" and "disingenuine" (sic), when they are trying to answer your question is against the ToS of C9.

I know I haven't necessarily been very diplomatic of late, but neither have you.

Let's move on.

"Diplomatic" isn't the term I'd use. You certainly go well beyond "answering" questions and clearly are here to defend Microsoft by changing the issue altogether and "creative enhancing" what people say. You can repeat that example of mine you site over and over but we both know it was my sarcastic attempt to mimic you.

You're probably right though about getting banned since we know as long as you defend Microsoft you can infer anything without worrying about the ban hammer.. 

Hey if you're willing to have honest discussions here rather than bending things like you do then by all means let's put down the swords.

9 hours ago, evildictait​or wrote

*snip*

But my suspicion is that like a lot of features "demanded" on the interwebs, there's a fairly limited set of people that really want this feature, and a fairly large number of people that want the features higher up the list.

I suspect that a lot of people just want their technology to just work and will move on to whatever works best for them.

1 hour ago, kettch wrote

This is a pet peeve of mine, but has anybody who insists that this is a vital feature actually used Microsoft designated channels for asking for it? I just did a search for anything related to macros on the Uservoice site, and there was nothing there.

http://windowsphone.uservoice.com

You're right; this should get logged. It's too bad Joe Business User who runs into this sort of thing doesn't typically know about UserVoice and instead just curses Microsoft and moves on.

I'll post something there later today.

BTW, I don't think anyone called this a "vital feature". It's just one more PITA that gets in peoples way. I'm not sure why you hype it up like that.

Oh yeah the same old dismissive excuses.

Have you ever written software that was sold to customers? I'm seriously asking, and for what company, so I can avoid it.

1 hour ago, kettch wrote

*snip*

Have you ever written software that was sold to customers? I'm seriously asking, and for what company, so I can avoid it.

++

1 hour ago, kettch wrote

*snip*

Have you ever written software that was sold to customers? I'm seriously asking, and for what company, so I can avoid it.

That's what I do for a living believe it or not and my customers absolutely love me.

I love all of these swipes at me. No big deal. I'll just save them for the next time someone complains that these forums are too negative.

Cool?

At first it might not make sense that Microsoft has to test and debug functionality that they already tested and debugged -- until you realize that when Microsoft starts development on VERSION X of a product, they apparently start with an alpha copy of VERSION X MINUS 2 and go from there. It's the only way to explain a lot of regressions we've seen in the past with not only Office, but Windows as well. 

33 minutes ago, Craig_​Matthews wrote

The part being forgotten: Microsoft already knows how to open a macro-enabled Excel document, disable the macros, allow editing, and safely save the edited documents without breaking macros. It's part of the design of the file format, and it's been in every version of Office for the last decade.

At first it might not make sense that Microsoft has to test and debug functionality that they already tested and debugged -- until you realize that when Microsoft starts development on VERSION X of a product, they apparently start with an alpha copy of VERSION X MINUS 2 and go from there. It's the only way to explain a lot of regressions we've seen in the past with not only Office, but Windows as well. 

What makes you think that a feature in desktop office is free to port to a phone app that shares almost no code with the desktop app?

1 hour ago, evildictait​or wrote

*snip*

What makes you think that a feature in desktop office is free to port to a phone app that shares almost no code with the desktop app?

Because no one is asking for a feature to be ported from desktop Office to phone office. Phone Office already knows how to allow editing of editable data in an Office document. The file format itself separates the macros from content. Office on desktop, phone, and tablet, all know the difference between a macro and content, because they have to in order to open the file, and they have to in order to disable editing if macros exist. The portable Office already doesn't run macros, which no one is asking for it to do, and it already should know how to save an Office document without altering saved parts of the file that the user didn't touch.

Given the above, if allowing editing of macro-enabled documents without needing to touch the part of the file that has the macros, requires as much debugging and testing as you imply, great enough to just not even bother trying, then there's a more fundamental structural problem somewhere and I don't even need to see the code to know that. "fixing bugs in the sound subsystem can break printing" anyone?

2 minutes ago, Craig_​Matthews wrote

Given the above, if allowing editing of macro-enabled documents without needing to touch the part of the file that has the macros, requires as much debugging and testing as you imply, great enough to just not even bother trying, then there's a more fundamental structural problem somewhere and I don't even need to see the code to know that. "fixing bugs in the sound subsystem can break printing" anyone?

The problem is not whether you can open the file as editable. It's whether you can save it back again afterwards without deleting all of the macros. In order to save those macros back after you're done editing, you're going to need to parse them out in the first place so that you have something you can serialize back later. If you don't need to save back later (i.e. the document is readonly) you can just skip over the macros, but if you do need to save, you need to parse them into memory so that you don't lose them on the save back to disk.

Also, nobody is saying that enabling macros is a huge amount of work. I'm just saying it's more than zero amount of work, and that the people who would implement this feature aren't sitting around doing nothing. Doing more work requires a decision that the new work is more important than the current work that is being done.

Let's say it takes three man-weeks to make the document have macros that are editable - that's two days to put it in, a day to merge it, a day for MSEC to check it and two weeks to build unit tests and fix the bugs that inevitably occur. That's three man-weeks not being spent on other stuff.

So my question isn't should Microsoft implement macro-disabled documents being editable or a statement that it's too hard, can't be done. It's what stuff would you like the WinPho-Office team to not do, so that you can free up three weeks in their schedule for this feature that so far as I can see is being asked for by 4 people.

37 minutes ago, evildictait​or wrote

*snip*

So my question isn't should Microsoft implement macro-disabled documents being editable or a statement that it's too hard, can't be done. It's what stuff would you like the WinPho-Office team to not do, so that you can free up three weeks in their schedule for this feature that so far as I can see is being asked for by 4 people.

Now that's just disingenuous. You have no idea how long this will take to implement nor how many people want this feature implemented. I go to the trouble of putting it on UserVoice and you then use it as an argument against it. Nice. You totally ignore Joe Office worker who gets snagged by this limitation and doesn't know that UserVoice even exists. It's just baffeling at what lengths you'll go to in order to skew the argument in Microsoft's favor.

33 minutes ago, DeathBy​VisualStudio wrote

Now that's just disingenuous. You have no idea how long this will take to implement nor how many people want this feature implemented. 

Back at you.

It's just baffeling at what lengths you'll go to in order to skew the argument in Microsoft's favor.

Your personal attacks against me are getting tiring and are going quite a long way beyond plain rude. If you think Microsoft can magically implement extra features without diverting resources from other areas and features, that's your problem. But don't try and suggest that saying Microsoft having finite resources is somehow me "skewing the argument in Microsoft's favour".

1 hour ago, evildictait​or wrote

*snip*

No seriously, as far as I can tell, all that's being asked for this piece of mobile software is, "You see that vbaProject.bin file in the .xlsm file under the 'xl' directory? Yeah, ignore it's even there. Just don't touch it until the user hits save, then make sure that file, which hasn't been touched, is in the saved zip file."

* edited quote and to add:

Really --- if the phone version doesn't even support macros, there's no reason for it to touch the macro related files contained within the xlsm file. It kind of appears that someone had to do work in order to make it take a document with otherwise editable content and make it non editable because there's a file within the zip that provides extra functionality when used with a desktop client. Persisting unchanged files contained within a zip file to a newly saved copy of a zip file surely was thoroughly tested when "save" functionality was included I would hope .. at least to a point where Microsoft shouldn't be afraid of opening an Excel document write-enabled.

41 minutes ago, evildictait​or wrote

*snip*

Back at you.

*snip*

Your personal attacks against me are getting tiring and are going quite a long way beyond plain rude. If you think Microsoft can magically implement extra features without diverting resources from other areas and features, that's your problem. But don't try and suggest that saying Microsoft having finite resources is somehow me "skewing the argument in Microsoft's favour".

EvilD you and I both know that your remark of "so far as I can see is being asked for by 4 people." is nothing but skew. You can pretend all you want that it's meaningful information in order to make your point but it's flat out disingenuous. If you want to keep at spreading FUD by all means keep at it; I'll be here to call you out on it. Nothing personal.

2 hours ago, evildictait​or wrote

*snip*

In order to save those macros back after you're done editing, you're going to need to parse them out in the first place so that you have something you can serialize back later.

Do you have prove on this assumption?

Part of the hard job of product design is deciding which 20 features you have the resources to pursue and which 180 to leave for next time.

55 minutes ago, evildictait​or wrote

I think there are several people on this thread who should read this post.

*snip*

13 hours ago, DeathBy​VisualStudio wrote

*snip*

 

 

Great. We should never discuss anything Microsoft missed, features we'd like to see, or directions that Microsoft took or appears to be taking because in the end it takes time, money, and resources. That should cut down a whole lot of threads here -- like maybe most of them.

 

Remember folks; Shhhhh... don't talk about that kind of stuff because it takes time, money, and resources. And even if you think you've got a good idea or think Microsoft got it wrong just remember one thing: you are wrong.

No, by all means, continue screaming loudly from every available thread how badly microsoft sucks and how this is just one more indignation through which you must steadfastly persevere.  

I'll try to avoid remembering that a healthy population of those 4 folks didn't even frikking know about it until this thread.

Carry on, brave soldier.