Method Community

I see a post on Debugging - http://www.methodintegration.com/cs/forums/p/1499/5216.aspx#5216 - from back in February. I'm new to using Method and I'm adding a bunch of Action steps to calculate and update values on a screen both in and out of a grid. I need to see if the values are being calculated correctly (b/c my initial script seems to be doing NOTHING). It seems enabling Debug or inserting ShowMessage in places might work but it's really not that useful if it doesn't work inside a loop...that's basically what I'm doing is looping and calculating inside a grid when it's saved. It seems Method could just use the ASP.Net tracing and debug statements like the framework allows -- e.g. every ShowMessage Action step we insert could turn into a Tracing/Debug message that the .Net framework would emit. I dunno...just thinking as I write this.

I know this...it's pretty much impossible to debug my Action steps right now.

Have their been any Debugging feature improvements since the post in February that might help me Debug my actions?

It's entirely possible I'm going about solving my problem in an abnormal way, also.

Any help would be much appreciated.

Hi Blake,

Currently the only method of debugging in Method are the ones listed in the forum post you linked. I believe that Enable Debug tracing does work with loops. One additonal thing you could do is create an action result that stores that values that are generated at each row of the loop and just show them at the end of the loop.

-Michael

Blake,

I'm curious as to how you're making out with this.  I never really resolved the issue of how to debug more complicated logic as messages provided by Method in debug mode are a bit dumbed down, friendly and chatty, but not very useful.  The only technique that appears available is to use the Show Message Action, and I've had lot's of problems with that one as well, and it's terribly cumbersome to add and move a bunch of Show Message Actions into place in a long sequence of Actions as you have to incrementally move them one step at a time in the action sequence and the screen jumps the scroll position on each move.

I can understand why the developers wouldn't want users to have access to the verbose mode of logging from ASP.net, but sometimes I feel like I'm flying blind.

Cheers,

James

Since my initial post I have not worked on it any further. Without better testability, we ARE flying blind.

When I developed software for a living (10+ yrs up until last year), executing full regression tests via automated web UI testing (with Watir/Watin or some other tool that is programmable) was part of the development process. If I'm going to commit to Method for my business (nowhere near deciding on this), I would probably try to use a tool like that to make sure things like calculations on a page are executing correctly. It's a lot of work, though....but necessary if you like predictability and consistency with your software solution that happens to be running your business.

In the real world, ShowMessage just doesn't cut it when we are trying to determine if our systems are working correctly or not on the web.

The really big question re: automated web UI testing of Method is whether or not their HTML is compliant and therefore workable from a test tool. In my experience it's best to have a lot of control overe the HTML generation. This helps create better tests, more easily, if that makes any sense.

Would like to hear Method devs chime in on this more and provide guidance if possible.

Blake,

It's been really hard for me to adjust to "flying blind" compared to other systems I've integrated/supported/etc., but I can say I've found the overall Method platform really stable and I think the developer's have done a really good job of providing tools for the non-software development user that are robust enough to provide some pretty powerful application development without writing code or really undestanding what's happening under the hood.  I think the choices they have made as to how much to show the user/application developer are on balance very clever and the more I use the system the more I appreciate the elegance of the limited but powerful feature/tool set.  Someone had a crystal clear vision of how this would work when they built Method.

That said, I don't think I would have been succesfull without having some background in relational database structures and systems integration experience.  There just isn't enough good documentation for someone without some background to just jump in and start integrating apps with QB.  Not to mention understanding QB's data structures.

But, the support has been really fantastic.  The folks monitoring the forum are always available and very competent and willing to address posts as trouble tickets.

Ultimately, I think it's a business model question.  To truly be successful as an application developer I think some sort of "Value Added Reseller" relationship with Method is required and for software developer's like yourself you're going to need to get into the inner technical circle of Method.  I'm sure they have ways to open up verbose debug logging of ASP.net.

I'm very happy with the progress I've made as an independent user/business owner/application developer, but I hired a Method consultant to get me started and I plan to engage with them for ongoing support and enhancements so I don't walk too far out on the limb by myself.  Without going to the user conferences, etc., and developing a rapport with the technical staff of Method, I'm not sure how deep into application development I can go, there just isn't enough documentation.

I agree with this approach though as folks like me would tie up too many resources for support if allowed direct access.  I want and need Method to continue to be successful which requires a lot of user's with a manageable level of support.  I don't want Method to be like Intuit which is a black hole of support, but I know they need some volume to make the business model profitable.  I think the Method development team has really been doing fantastic work rolling out new functionality and improving stability with a minimum of change related bugs and I really want to see their hard work pay off financially.

Of course I've also invested a tremendous amount of time to configure Method for our company and now I'm full dependent on the continued success of Method for my companie's production system, so I could just be cheerleading.

Hi Guys

Here's a simple trick to aid in debugging especially in a loop.  Add a label object to the screen with the caption debug.  Within your loop you can use the action "enter value into field on screen"  to update the label caption with the variable in question. If you need to see what's happening at each loop increment, you can concatenate the label with each subsequent increment.

The beauty of this is when you're done debugging you don't even have to modify your code.  You can just hide label.

Hope this helps

Good points all around. Thanks for your insight.

I'm no longer a software developer. I just joined my family's business and I'm trying to move our process away from the obvious constraints of a paper-based system. I found Method b/c it extends QB's built-in capabilities for items, estimates, orders, and invoicing. I didn't want to write this functionality again (or pay someone to do it). We use QB, but not the way it should be, from what I can tell...so that's actually another large hurdle in my company to deal with.

I'll definitely consider hiring a Method developer to help consult as I get a better idea of how Method might work for us...like you said...to make sure I don't go too far out on a limb as I begin to tailor Method for my business' purpose.

Thanks again..

Thanks for the debugging label tip, too. Not great, but it'll have to do in a pinch.

Much appreciated.

LaCrews, great tip on debugging, much better than Show Message!  Great idea.

Now if we could just get that Label to concatenate the debug values we might actually have some debug logging that works.........

Thanks.

Oh, and Blake, I'm doing something very similiar in our family business.

We use QB Enterprise for Accounting and the Back End, and Method to create a user interface for entering Orders, Scheduling, and Invoicing.  We could almost do everything in QB, but it wouldn't be as nice and QB just wouldn't do our pricing model and making a nice scheduling interface would have been almost impossible.

The Method Grid is an awesome tool for creating a scheduling and planning interface and the report tool is really good although totally undocumented.

It's really awesome to have a web based tool that can do everything Quickbooks can do as a seamless, live, synchronization to QB plus that extra 10% of functionality that we need for customization.

With the newly enhanced support for custom fields and some other functionality, QB Enterprise was almost flexible enough, but QB has had really limited support for Custom Fields in the past and they always just come up short.  That's really okay with me though as what QB does do, it does rock solid and I like them holding the line on functionality.  Every so often Intuit will drop support for something that forces you to buy an upgrade just to hold onto the same functionality, but it could be worse.

Instead of trying to teach the folks here to use the more arcane functionality of QB to get things done, I can guide the user to taking the right actions using the Method Interface and it gives me a lot of options for helping to preven mistakes and ensure better clerical accuracy.  Once you get used to the limitations of the relational model for screens and how screen functionality and the One to Many relationship of linked fields operate, you can develope applications really quickly.

Cheers,

James

James

Not sure if this was a question.  In any case you can get a string of comma separated values by using the action "character function" to concatenate each increment. 

Awesome! Thanks for the additional info. I may be messaging you directly with some of my questions in the near future since you have clearly done a lot of dev work with Method to this point :-)

Do you use the same QB company file for both your Accounting and Back End? Having all this stuff - e.g. product catalog, estimates, orders, and invoices - syncing to the same QB file for accounting here gives my finance dept (my mother - gotta love small family businesses) no small amount of concern. There's really only 2 people here that would need access to QB directly. Me and the afore mentioned finance dept. The rest would be accessing everything thru Method online.

I too like the idea of customizing web-based views and screens for my users to better fit how we work.

How is the Method API? I've considered creating the technology for other functions of my business (the truly custom stuff we do) in another technology/platform and integrating through events somehow in and out of Method. I just haven't proven a real need for it, at this point obviously. Just wondering what that experience might be like.

Thanks

Blake,

I'd really enjoy sharing what I've learned so far.  Just PM me and we'll get hooked up.

Regarding the QB back end to Method, it really works great.  I had my concerns, but when you get down to it, QB just really needs the "Posting" transactions.  So for example with Quotes, Orders, and Invoices, QB really only needs to get the Invoice Line Items to post to A/R, then you can receive payments directly into QB.

So, as we are using Method, we have a production front end for users to create Estimates, Orders, and Invoices and associated reports, but we'll do most of the accounting functions directly in QB.

But, the Method synchronization is really seamless and all of the Non Posting records sync really well, back and forth to QB, and so far really robust.  Once you start to really pay attention to Posting versus Non Posting transactions it becomes apparent how it is possible to have the accounting data hold rock solid an with minimal opportunity for conflicts, while using Method to create new functionality.

Or, as another example consider the Items table in QB.  QB only really needs Item Name, Item Type, GL Account and Price to do all of it's posting for accounting purposes of Invoices, and all QB needs is a correctly formatted Invoice Header record and Invoice Line Item record.

Now Method is keeping an identical copy of the Items table, but with all your additional fields that might be required for other functionality.  Method maintains a strict discpline such that you will always post the minimum required information for QB to function and has implemented the relational structures to hold this integrity at the RDBMS level, I believe.  I'm not sure, but I believe the database engines would have to break certain key field and relational structures for corruption to actually occur so the logic for synching is really more a brute force comparison as to who's got the most recent data, which is also configurable.  I currently have my synch setup to have QB win in a conflict, but I'm not sure recency isn't better.

I haven't looked at the API as really all I want to do is be able to create good front end apps and I want to use a "toolkit" that a bunch of other people are using so that if the lower level code has a problem, I'm not the only one experiencing it.  I really don't think the Method API is necessary for basic business apps.

You can put security on QB for multiple users, but towards your Mother's concerns, I really like the idea of giving only a few people direct access to QB, and the rest will have to come in through Method, which also has a really good security model.  Plus then I don't have to update all desktop clients with the latest QB release, worry about using Single User Mode in QB for accounting functions and kicking people off the system, etc.

I have installed the Method Synch Engine on multiple computers, but really I just keep a QB session open on the QB server and a Method Synch Engine running so all Method synch activity is confined to one machine and the clients are just using the browser sessions.  I use Terminal Services to log into my Win 2003 Server to keep the QB session and Method Synch Engine up and running.  It works like a champ and I can work from anywhere.

The performance in Method is also proving very good, I'm using Chrome right now as it has the best Java Virtual Machine, etc., but Method works fine in Firefox and IE.   The cross browser support is really good, and it gives me a lot of confidence in the Method developers as it can be really difficult to get an app to display correctly accross browsers.  They're doing something really right to get all these screen widgets to work so well accross browsers.